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Your Instructors 

This week your instructors could be any combination of the people listed 
below. If you have any comments about the course structure or content, feel 
; Tree to rn 

Jim Herz <Herz:OSBU North:Xerox> 

' Gail Kubeczko 
Holly Wanless 
Grant Ruiz 
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Available XDE Training 

Here is the ordering in which XDE training should be done. Bold boxes 
represent self-paced tutorials. The numbered boxes represent stand-up 
courses offered by our Training Group. Classes are usually held in Sunnyvale, 
California. Descriptions of each are on the following pages. 



XDE Intro 



1. Mesa 



Mesa Course Tutorial 




2. XNS 



3. ViewPoint 
Programming 



ViewPoint 
Programming 
Tutorial 



5. Next Class 
(stay tuned) 




4. Advanced 
ViewPoint 
Programming 
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The Stand-Up Courses 

UNIT1. The Mesa Language 

Introduces a new user to the Mesa programming language. Stress is 
placed on possibly unfamiliar features such as explicit storage 
management (allocation and deallocation), modules and configurations, 
monitors, processes, and signals. System issues are not covered in detail. 

UNIT 2. Introduction to Xerox Network Systems Protocols and Agents 

Defines the Xerox Internet Transport Protocols. Emphasis on definition 
and Illustration of Network Systems remote procedure call protocol 
(Courier). Examination of service-like applications interacting with top 
level protocols. 

UNIT 3. Xerox ViewPoint Programming 

In this unit we introduce ViewPoint architecture, user interface, tool set, 
and design methodology for applications built on the ViewPoint base. 
Topics covered include Programmer/User interaction, running programs 
from the desktop, registering programs with the desktop, NS file 
manipulation, and application folders. 

UNIT 4. Advanced ViewPoint Programming 

This class will focus on writing applications that interact with documents 
and other applications in a sophisticated manner. Topics will include 
using advanced graphics, notifying procedures when user actions occur, 
writing and managing TIP (Terminal Interface Package) tables, and 
managing a selection. 
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The Self Study Materials 

• XDE Concepts and Principles 

A high level overview of XDE and Xerox Network Services architecture. 
Intended to provide a philsophical and conceptual framework on 
which to base an understanding of XDE. 

• Introduction to XDE 

A computer aided tutorial that will familiarize a new user with the 
XDE tool set and associated user interface, operation of essential tools, 
editing, and XDE documentation. This tutorial will take two to three 
days to complete. 

• The Mesa Course 

A self paced Mesa Language programming tutorial that includes 
representative instructional software and is intended for use at a 
customer site, Its purpose is to provide instruction in tool development 
skills and familiarize a new user with basic Mesa and Pilot interfaces. 
This course will take four to eight weeks to complete. 

• The ViewPoint Programming Course Tutorial 

A self paced programming tutorial completed at the customer site; it is 
designed to follow the one week Xerox ViewPoint Programming 
Course. The ViewPoint Programming Tutorial assumes that you are an 
experienced Mesa Programmer. The course covers the range of 
programming skills required for development of sophisticated 
ViewPoint applications. The course with all exercises will take three to 
eight weeks to complete. 
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Course Objective 

Need: The Mesa language is one of the cornerstones of the Xerox 
Development Environment. Being a proficient Mesa programmer is an 
essential first step to effective use of the power of XDE. 

Objective: Graduates will be able to prepare, compile, debug, and run Mesa 
programs. These programs will exercise features of Mesa that are new or 
unfamiliar to most students. 

Please Note: This class is NOT geared to teach basic computer science topics. 
We assume that you are EXPERIENCED programmers. We will teach 
experienced programmers how to program in the Mesa Language. 



Do: Ask questions at any time. We may, however, defer answering some 
questions or ask you to submit them through the mail system. 

Submit your course evaluations daily using the mail system. 

Have fun. 

Don't: Instigate religious debates by touting your favorite (non-Mesa) 
language. We are here to teach you Mesa. 

Expect to learn everything about Mesa in one week. We will get you 
started in the right direction. 
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We're Not Your Mother 



The general format of the class is lecture in the morning, lab in the 
afternoon. The lab has no format: you are expected to complete your 
assignments (or at least try) but you can come and go as you wish. 

Major No-No: Don't leave for three hours in the middle of the afternoon 
and then come back and expect us to stay herewith you until 10 PM. 
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Day 1 - Monday 

9:00-9:45 Introduction and Course Organization 

Training Overview 
Mesa Language 
Pilot Operating System 
Physical and Logical Volumes 

9:45-10:15 Getting Started in Mesa 

The Fundamental Module Types 
What a PROGRAM module looks like 
Comments 

Basic Data Types and Expressions 
10:15-10:30 Break 

10:30-12:00 Getting Started in Mesa (Cont'd) 

Common constructed Data Types 

Statements 

Procedures 

Additional data types, Extensions 
The Debugger 
12:00-1:00 Lunch 

1 :00-6:00 Debugging and Compiling Exercises 

Ask for Solution when finished 



Training Overview 



Mesa Language Class - March, 1988 



lntro-9 



Daily Schedule (Cont'd) 



Day 2 -Tuesday 



9:00-10:15 Interfaces 

Review Definitions 
Opaque Types 

Examples of Interface modules 

Examples of Program modules 
10:15-10:30 Break 
1 0:30-1 1:15 Interfaces (Cont'd) 

Examples of configurations 

More Examples 
11:15-12:00 Interfaces Exercise 
12:00-1:00 Lunch 

1 : 00-6: 00 Interfaces Exercise (Cont'd) 

Ask for Solution when finished 



Day 3 - Wednesday 

9:00-10:30 Dynamic Storage Allocation 

Different types of heaps 
Declaring and creating heaps 
Allocating and deallocating from heaps 

10:30-10:45 Break 

10:45-11:30 Form Subwindow Layout Tool 
11:30-12:00 Dynamic Storage Allocation Exercise 
12:00-1:00 Lunch 

1 :00- 6:00 Dynamic Storage Allocation Exercise (Cont'd) 

Ask for Solution when finished 
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Daily Schedule (Cont'd) 



Day 4 -Thursday 



9:00-10:15 Signals 

Signal Examples 

Operations with signals 

Catch Phrases 

UNWIND signals 
10:15-10:30 Break 
10:30-11:30 Streams 
1 1 : 30-1 2: 00 Streams / Signals Exercise 
12:00- 1:00 Lunch 

1:00- 6:00 Streams /Signals Exercise (Cont'd) 

Ask for Solution when finished 



Day 5 - Friday 

9:00-10:30 Processes and Concurrency 

Concurrent execution 

New language features for processes 

Monitors 
10:30-10:45 Break 

10:45-12:15 Processes and Concurrency (Cont'd) 

Condition Variables 
More about monitors 
Signals 
Deadlocks 

Other operations on processes 
12:15-1:15 Lunch 
1:15- 6: 00 Monitors Exercise 

Ask for Solution when finished 
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What is Mesa? 

• A programming language 

• An operating system, Pilot 

• A processor architecture 
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History of Mesa 

• Research started at PARC in 1971 

• Went into production use at Xerox (OSD, ISD) DSBU in 1976 

• Various Mesa machines include the Alto, Dandelion, Dorado, Daybreak 
(6085). 
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Architecture Highlights 

• High-level Language Oriented 

• Stack Machine: 16 bits wide, 8 - 14 words deep 

• Large Shared Virtual Memory 

32 bit address space, 256 word pages 
Word addressed, 16 bit words 
64K word Main Data Space 

• Shared code and Data 

Read only code, shared across modules 
Global (static) data shared across processes 

• Procedure Oriented 

Parameter passing on stack 
Heap allocation of activation records 
Single transfer primitive (XFER) 
Local and Global calls, single return 

• Process Mechanism 

Preemptive event driven scheduling, 8 priority levels 
Monitors and Conditions 
Interrupts, Timeouts, and Aborts 
Fork any procedure 

• Dense Instruction 

Average instruction is 1.4- 1.5 bytes 



Training Overview 



Mesa Language Class - March, 1988 lntro-14 



Advantages of Mesa 

• Support of large scale system application development through direct 
and efficient support of structured, modular programming. 

• Reduced product costs through 2x programmer productivity gain 

• Efficient machine implementations 
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Mesa Language 

• High level systems programming language 

• Strong type checking 

• Modular programming 

• Flexible control transfer mechanisms 

• Concurrent processes with protected, shared data 

• High density object code 
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The Mesa Language 

Mesa is a language that is basically similar to Pascal but which extends Pascal 
in a number of directions intended to make it more effective for the 
development of large systems. Mesa features include (among others): 

• Rich Type System 

Basic: BOOLEANs, CHARACTERS, INTEGERS, CARDINALS, REALs 

Constructed: Subrange, Enumerated, ARRAYS, RECORDS, POINTERS, 
STRINGS, Variant RECORDS, PROCEDURES, PROGRAMS, SIGNALS, 
ERRORS, PROCESSes 

• Simple Control Structures 

Statements: Assignment, IF, SELECT, FOR, WHILE, DO 
Compounds: Blocks, PROCEDURES, PROGRAMS 

• Module Structure 

Interfaces: DEFINITIONS modules 

Clients and Implementors: PROGRAM modules 

Systems: CONFIGURATION modules 

• Explicit Storage Management 

Heaps and Zones 

• Exception Handling 

SIGNALS and ERRORS 

• Concurrent Processes 

Creation and Destruction: FORK, JOIN 
Locking: MONITORS and ENTRY procedures 
Synchronization: CONDITIONS, WAIT, NOTIFY 
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Mesa Features with no Pascal Counterparts 

• Type checking across separately compiled modules 

• Interface modules 

• Concurrent process support 

• Procedure variables - procedures are a full fledged type 

• Explicit storage management - no garbage collection 

• Default field values 

• Base and relative pointers 

• Pointer arithmetic 

• Constructors and extractors 

• Exception handling mechanisms 
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Pilot: The Mesa Operating System (Overview) 

Pilot defines a "Basic Machine" that is an abstraction of the physical 
resources provided by the hardware. The purpose of the basic machine is to: 

• Define a standard interface that is independent of the size, speed, model, 
and configuration upon which it is operating 

• Provide a uniform environment for program design 

• Insulate clients as much as possible from variation in hardware 
configuration 
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Facilities of Pilot 

• Runtime support for the Mesa Programming Language including Mesa 
processes. 

• Virtual Memory Management. 

• Local Disk Management, for local file system setup and manipulation. 

• Packages for management of processes, physical memory, bitmap display, 
and CPU. 

• Device I/O Package, for local peripheral management. 

• Communications package, for network streams, packet exchange, 
modem support, and other basic communication services. 

• Streams for handling sequential I/O in a device independent way. 

• Common Software, for handling device I/O, strings, and formatting. 

• Diagnostics, for detecting and analyzing hardware problems. 
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Pilot is Not a General-Purpose Time Sharing System 

• No master/slave mode; no protection against malicious programs 

• No enforcement of resource allocation/billing/accounting 

• Client assumed to be a collection of cooperating processes 

• Client controls specialized devices directly 

• No user interface 
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The Main Data Space 

The Main Data Space (MDS) is a contiguous region of 64K words of virtual 
memory. Its purpose is to allow the most commonly used data structures to 
be referenced by single word pointers rather than double word pointers. 

• It is used mostly by low level system clients. Generally, application 
programmers should not allocate storage for user data from a MDS. 

• User storage allocated from the MDS is referenced indirectly using 
POINTERS, any other storage is referenced using LONG POINTERS. 

Note: In pre Pilot 14.0 releases, both Local and Global Frames are allocated 
from the MDS. In post Pilot 14.0 releases, Local frames are allocated from 
the MDS but Global frames are allocated from an anonymous backing store. 
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The Xerox Development Environment 

• XDE (Xerox Development Environment) is the programming environment 
for our products. 

In XDE, one can write programs for XDE itself as well as for the 
Viewpoint, environment. As an example of what can be done with 
XDE, all of XDE, Viewpoint and Network Services was developed using 
Mesa in the Xerox Development Environment. 

• XDE includes everything the programmer uses: 

- all programming tools and applications 

- all programming interfaces 

- all support materials 

- product support 
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XDE Support 

How you get initial support for XDE depends on who your company is. 
If you are a: 

Xerox internal programmer, contact: XDEConsultants: All Areas.Xerox 

Rank Xerox employee, contact: XDESupport:SBD-E:RX 

Commercial customer, USMG Analyst, USMG Sales Rep, contact: 
XDESupport:OSBU North:Xerox 
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System Configuration 



• A physical volume is the basic unit available for random access file page 
storage. A Physical volume corresponds to a storage device, typically a 
disk. 

• A logical volume is a partition of storage for client files, including system 
data structures for manipulating those files. 

Typically, a physical volume is divided into one or more logical volumes. 
Each logical volume is largely protected from actions in other logical 
volumes. Different logical volumes contain different systems. 



Volume Name 



Contents 



User BWS bootfile, Viewpoint data files and applications 

Scavenger Can be used as backing store for the User volume; 

File system recovery software for the User volume is 
located here, if needed 

CoPilot CoPilot bootfile [pre-14.0 releases only] 

(CoPilot bootfile = Tajo bootfile + built-in debugger), 
plus debugging files, XDE tools, XDE user files 
** OR ** 

Tajo bootfile & Sword [12.3 releases or later only] 
plus debugging files, XDE tools, XDE user files 

Tajo (If present) Tajo bootfile, XDE tools 

A standard configuration for Viewpoint developers might be a User and 
Scavenger volumes for Viewpoint and one XDE volume running Sword 
(Same WOrld Debugger). 
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Graphically Speaking 



Debugger. out load 



Boot 

Microcode 



Debuggee. out load 



XDE Tools 
incl: SWorO 



Ta jo. boot 



Diagnostic 
Microcode 



Germ Microcode 



Pilot Microcode 



XDE 
Tools 



Tajo 
.boot 



Programmer 
Created 
Viewpoint 
Applications 



Standard 

Viewpoint 

Applications 

(Editor, 
Printing, 
Mail, Fonts, 
etc.) 



BUS. boot 



CoPllot 



Tajo 



User 



Scavenger 



Disk Sectors: each with Header, Label, and Date 
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World Swapping 

With the CoPilot debugger, you can only keep the state of one client around 
at any given time. 

With Sword, you can debug multiple clients! In addition, Sword can debug 
in the same world, as well as be the resident debugger for client volumes. 

For world-swap debugging, you must boot the client volume once in order 
to establish a debugger-client relationship. But once that relationship is 
established, it is easy to swap between the debugger and the client. 



1. Boot: Tajo 
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Getting Started in Mesa 
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Outline 



1. Getting Started in Mesa 

a. The Fundamental Module Types 

b. What a PROGRAM Module looks like 

c. Comments 

d. Basic Data Types and Expressions 
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Compiling Modules 



f i lename .mesa 



source 
code 



compiler 



f 1 1 ename . be 
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Modules 



Definitions 



Program 



Configuration 



✓ \ 
/ \ 
/ \ 
/ \ 
/ \ 
/ \ 
/ \ 
/ \ 
/ \ 



Client 



Implementation 



Definitions files (a.k.a Interfaces) define an abstraction. 

Program files contain executable code that implement the abstraction. 

Configuration files specify how program modules are combined. 
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Program (Client) and Definition Modules 



ReadDef s .mesa 



ReadDefs: DEFINITIONS = 
BEGIN 

ReadChar: PROCEDURE; 
END. 



Definitions Module 



DoWork.mesa 



DoWork: PROGRAM = 
BEGIN 

ReadDefs . ReadChar[] ; 
END. 



Program Module 
(Client) 

The PROGRAM module, DoWork, is using the procedure ReadChar that is 
defined in ReadDefs. The implementation of ReadChar is unknown to this 
module. 
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Program (Implementation) and Definition Modules 



ReadDef s.mesa 



ReadDefs: DEFINITIONS = 
BEGIN 

ReadChar: PROCEDURE; 
END. 



Definitions Module 



Readlmpl .mesa 



Readlmpl : PROGRAM = 
BEGIN 



ReadChar: PUBLIC PROCEDURE 
BEGIN 



END; 



END; 



Program Module 
(Implementation) 

The PROGRAM module, Readlmpl, supplies the actual implementation for 
the procedure ReadChar that is defined in ReadDefs. 
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Fitting Client and Implementation Modules Together 



DoWork. bed 




Readlmpl . bed 


DoWork: PROGRAM = 




Readlmpl : PROGRAM = 


BEGIN 






BEGIN 

ReadChar: PUBLIC 


ReadDef s . ReadChar[] ; 


< 




PROCEDURE = 
BEGIN 






END. 


needs supplies 
ReadChar ReadChar 


END; 
END; 



\ 



/ 



Executabl eVersion . conf ig 



Executabl eVersion 
CONFIGURATION = 

BEGIN 

Readlmpl ; 

DoWork; 
END. 



Binder 



Executabl eVersion .bed 



A CONFIGURATION file brings together the PROGRAMS DoWork and 
Readlmpl so that the implementation for ReadChar is around when DoWork 
calls for it. 
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Program Module Structure & Syntax 

DIRECTORY 

<Interf aceNamel> USING [<ProcNamel> , ...], 
<Interf aceName2> USING [<ProcNamel> , . ..], 

« 

<Interf aceNameN> ; 

<ModuleName>: PROGRAM 

IMPORTS <Interf aceNamel>, <Interf aceName2> 
EXPORTS <Interf aceNameN> = 

BEGIN 

<type, variable, procedure decl arations> ; 

<main code, if any> 

END. 



Note: {...} is an alternative to any BEGIN. ..END. 
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Program Module Example 

DIRECTORY 

Stream USING [GetBlock, Delete], 
Window USING [Create], 
ReadDef s ; 

Readlmpl : PROGRAM 

IMPORTS Stream, Window 
EXPORTS ReadDefs = 

BEGIN 

• • • 

n: CARDINAL <- 0; 

• • • 

DoSomethinglnteresting: PUBLIC PROCEDURE = { 
h 4- Window. Create[ ... ]; 
WHILE n < 100 DO 

• • • 

Stream.GetBI ock[ . . . ] ; 

• • * 

Stream. Del ete[ . . . ] ; 
ENDLOOP; 

}; 

• • • 

END. 
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Comments 

— This comment is terminated at the end of the line. 

IF i = 1 — Middle of line comment — THEN 

«This comment ignores all 
carriage-returns. It ends here.>> 
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Identifiers 

Identifiers can be any mixture of upper letters, lower case letters, and digits. 
The first character must be a letter. Upper and lower case letters are 
different and do distinguish identifiers. All characters are significant. 

Examples: 

aBc 
Abe 

Di skComm and Word 
di spl ayVector 
machl 
x32y40 

Mesa Reserved words are always all upper case. For a complete listing see 
Appendix E of the Mesa Language Manual. 

Examples: 

BEGIN 
END 

PROGRAM 
INTEGER 
CARDINAL 
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Built-in Element Types 



(INT)EGER 



W N-1 mm 2 N-1 } 



-N = 16 



(NAT) URAL - 




- INTEGER H CARDINAL 



CARDINAL - [Q..2™) 
(BOOL)EAN - FALSE | TRUE 
(CHAR)ACTER - all characters: 
Examples: 

TowerCaseA: CHAR *■ 'a; - character literals are assigned with a single quote 

mark: CHAR «■ ' ; 

endMarker: CHAR ' ; ; 

asciiCR: CHAR + 15C; -octal 

tab: CHAR «- \t; — escape convention 



[] indicates inclusion 
0 indicates exclusion 
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LONG INTEGER and LONG CARDINAL 

LONG INTEGER - [-2 2N " 1 .. 2 2N " 1 ) -N = 16 
LONG CARDINAL- [0 .. 2 2N ) 
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REAL 

Mesa has adopted the proposed IEEE standard for floating-point arithmetic. 

Examples: 

4.32 
0.15 
8.0E-19 

The mantissa is therefore represented by 24 bits (including the "hidden bit") 
with the decimal point to the right of the first bit; the exponent is 
represented by 8 bits with a range of -126 to 127 (All 0's and all 1's are 
exceptional conditions). 
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Declarations 

All identifiers must be declared in one of 3 ways: 

Simple declaration: 

<identif ier>: <type>; 

Initial Value declaration: 

<identif ier> : <type> <- <initial va1ue>; 

Constant declaration: 

<identif ier> : <type> = <constant va"lue>; 

Examples: 

first: CARDINAL; 
condition : BOOLEAN; 
pageCount: CARDINAL <- 0; 
isOn; BOOLEAN <- TRUE; 
pi: REAL = 3.141562; 
indirectPi: REAL = pi; 

startingPageCount : CARDINAL = pageCount; 
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Numeric Operators 

+ - / * MOD 

/ truncates toward zero for integers 

mod yields the remainder of dividing 2 numbers 
It does not apply to REAL operands 
The sign of MOD is the sign of the dividend 

Examples of various expressions: 

n 

15 

(1 + J + k) 
-15 

3.14 

m*n 

n MOD 8 - the result has the sign ofn 
i + 1 

Exponents, powers, and roots are implemented in software. 
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Relational Operators 

The operators below apply to all ordered types 

<<= = #>>= 

NOT 

IN <1nterval> 

Examples of various expressions: 

n = 5 
m # n 
m ~ a n 

1 < a J 

(1 < j) - (j < k) 

n IN [1..5] 

1 NOT IN [-1. .5] 
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Boolean Operators 

NOT ~ AND OR 

Evaluation is from left to right and stops when the value of the expression 
has been determined. 

Examples of various expressions: 

NOT i = 15 

~q 

~(p AND q) 

i <■ j AND j < k 

p AND ~q 

1*5 AND j NOT IN [-1. .1] 
m>n OR m- 5 
~p OR ~q 
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Character Arithmetic 

A CHARACTER value plus or minus a short numeric value yields a 
CHARACTER value. 

Subtracting 2 CHARACTER values yields an INTEGER value. 

Examples: 

c: CHARACTER <- 'c; 
digit: INTEGER; 
digit c - '0; 

c c + ('A - 'a); -converts lower case to uppercase 
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Function-like Operators 



PRED SUCC - used with all element types and LONG CARDINAL and 

LONG INTEGER. The values of PRED[x] and SUCC[x] are 
the predecessor and successor of x respectively. 

ORD - converts a character or enumerated value into a numeric 

value. 

val - is the inverse of ORD: 

c : CHARACTER <- VAL[101B]; 

FIRST LAST - used with all element types and LONG CARDINAL and 

LONG INTEGER. These yield the least and greatest values 
respectively. 
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Precedence 

Operators in order of decreasing precedence: 
+ - unary operators 

* / MOD 

+ 

# < <= > >= IN 

NOT 

AND 

OR 

<- 

Parentheses can be used to explicitly control the association of operands 
with operators. 



Getting Started in Mesa 



Mesa Language Class - March, 1988 



1-22 



Static Type Determination 

The inherent type of every expression and variable in Mesa can be 
determined by static analysis. 

Type rules in Mesa take 2 forms: 

Target Type Rule: The inherent type of a variable or expression must 

conform to a target type. 

Balancing Rule: The inherent type of a variable or expression must 

satisfy a relation for a known set of types. 

*Type A conforms to another type B if Mesa can convert a variable of type A 
to be of type B at runtime. 
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Target Type Example 

x: INTEGER; 



x «- y; 




type: type: 
INTEGER unknown 

TYPE unknown must conform to TYPE INTEGER. 
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Balancing Example 



x: INTEGER; 

y: LONG INTEGER; 



. . . x + y 




type: type: 
INTEGER LONG INTEGER 

An INTEGER cannot be directly added to a LONG INTEGER; balancing must 
take place. 
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Bounds Checking 

When mixing numeric types: 

Not aii CARDINALS are valid INTEGERS 
Not all INTEGERS are valid CARDINALS 

Not all LONG INTEGERS are valid CARDINALS (using a range assertion). 



If bounds checking is requested of the compiler (switch b), code will be 
inserted before each cross assignment to ensure that the value is within 
range. 

Otherwise, it is the responsibility of the programmer to ensure that the 
conversion is valid. 

Examples: 

i: INTEGER; c: CARDINAL; 

c 4- 40000; 

i «- c ; - With the b switch, this generates a bounds fault 
- (because this is a cross assignment) 
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Domains of Numeric Operators 

When the result of an operation falls outside the range of its assumed type, 
overflow or underflow occurs. 

It is the programmer's responsibility to guard against overflow and 
underflow conditions. 

Examples: 

i , j , k: INTEGER; 
a,b,c: CARDINAL; 



1 <- 30000 
j <- 30000 

k <- 1 + j 



k has value -5536 (all variables are INTEGERS) 



a <- 4; 
b <- 5; 
c <- a - b; 



c has value 65535 (all variables are CARDINALs) 



k <- a - b; 



With the b switch, this generates a bounds fault 
(because this is a cross assignment) 
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Outline 

1. Getting Started in Mesa (cont'd) 

e. Common Constructed Data Types 

i. Type Conformance in general 

ii. The element types 

iii. Arrays 

iv. Records 

v. Pointers 

f. Statements 

i. Assignment statements and expressions 

ii. IF statements and expressions 

iii. SELECT statements and expressions 

iv. Blocks 

v. Loop statements and loop control 
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Conformance and Constructed Data Types 

In an assignment statement, the right side must conform to the left side. 
B<-A 

There are 3 relationships a type A may have to type B: 

A conforms to B. 

A freely conforms to B. 

A is equivalent to B. 

is equivalent immm freely conforms conforms 

Equivalence - Mesa sees no difference between type A and type B if A 

and B are equivalent. 

Free Conformity - At runtime, Mesa can store any value of type A into a 

variable of type B without checking, change of 
representation, or other computation if A freely 
conforms to B. 

Conformity-- Mesa can convert a variable of type A to type B at 

runtime if A conforms to B. (Runtime computation is 
required.) 

Often whether or not A conforms to B depends on whether parts of A are 
equivalent or freely conform to parts of B. 

Conformance issues related to specific Mesa TYPES will be covered when the 
TYPE is introduced. 
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Enumerated Types 

Enumerated types may be declared as in Pascal: 

Color: TYPE ■ {red, orange, yellow, violet}; 
foreground: Color; 
background: Color; 

Fruit: TYPE ■ {orange, lemon}; 

state: {disconnected, busy, available}; 

i: CARDINAL; 



foreground «- orange; 

background <- VAL[2]; - assigns yellow 

i «- 0RD[foreg round] ; - assigns 1 

IF Color[orange] > foreground THEN . . . 

Note that Color and Fruit are 'named' enumerated types while 
{disconnected, busy, available} is an 'anonymous' enumerated type. 

Conformance: 

Every appearance of an enumerated type definition generates a new type 
that is not equivalent to, and does not freely conform or conform to, any 
other enumeration. 

Therefore, 2 TYPE definitions with the same definitions, letter for letter, 
define different types. 
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Subrange Types 

Subrange types may be declared for all element types: 

day: CARDINAL[1 . . 31] ; 
year: CARDINAL[1900 . .1999]; 

Uppercase: TYPE = CHARACTER^ ' A . . ' Z] ; 
AssertTrue: TYPE = B00LEAN[TRUE . . TRUE] ; 

The basetype for a subrange is that type of which it is a subrange and which 
is not itself a subrange. 

The assignment of a value to a subrange variable makes an associated 
assertion that the value is in the appropriate interval. 

If bounds checking is requested of the compiler (switch b), code will be 
inserted before each assignment to a subrange variable to ensure that the 
value is within range. 

Otherwise, at is the responsibility of the programmer to ensure that the 
value is valid. 

Example: 

n: CARDINAL[0. .10]; 
m: INTEGER[-5. .5]; 

n <- n + 1; - not valid if n = 10 

n <- m ; -- only valid ifm IN [0 5] 
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Subrange Types 



The syntax for subranges follows mathematical notation: 



[] 
0 



indicate inclusion 
indicate exclusion 



The following intervals all designate the range from -1 to 5 inclusive. The 
endpoints of a subrange must be compile-time constants: 

[-1..5] [-1..6) (-2.-6) (-2. .5] 

The initial type identifier may be omitted if each bound in the interval 
specifies a short numeric value: 

si: [-10.. 10]; -signed rep 
s2: [100. .33000]; - unsigned rep 
s3: [0..10); - both reps 

Conformance: 

A subrange type conforms to its base type and a base type conforms to any 
of its subrange types. Subrange type T[i..j] freely conforms to T if 
1 = FIRST[T] and to T[i..k] if j < k. Two subrange types are 
equivalent if their base types are equivalent and if the corresponding 
bounds are equal. 
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Arrays 

An array variable can be declared like: 

<varname>: <PACKED> ARRAY <indextype> OF <componenttype> ; 
Or you can declare an array TYPE like: 

<name>: TYPE ■ <PACKED> ARRAY <indextype> OF <componenttype> ; 

And then array variables would be declared like: 

<varnamel> : <name>; 
<varname2>: <name>; 

Examples: 

IndexTyp: TYPE = [0. .10); 

ArrayTypel: TYPE = ARRAY IndexTyp OF INTEGER; 
ArrayType2: TYPE = ARRAY [0..10) OF INTEGER; 
nameArray: ARRAY [0..10) OF INTEGER; 
anotherArray : ArrayTypel; 

The <indextype> can be any element type. The <componenttype> can be any 
type including another array type. 

Arrays may be initialized when they are declared. 

Examples: 

octalChar: ARRAY[0..7] UF CHARACTER = 

['0/1/2/3/4/5/6/7]; 
dashes: ARRAY[0..7] OF CHARACTER <- [* -/-/-/-/-/-/-/-] ; 
dashes: ARRAY[0..7] OF CHARACTER <- ALL[ ' -] ; 
freshVector: ARRAY[0..3) OF CARDINAL = ALL[0] ; 
currentVector: ARRAY[0..3) OF CARDINAL freshVector; 



Getting Started in Mesa 



Mesa Language Class - February, 1988 



1-33 



Array Constructors 

Array constructors may be used to assign all the components of an array in 
an assignment statement: 

Triple: TYPE = ARRAY[1..3] OF CARDINAL; 
triplet: Triple; 

triplet «- Triple[ll, 12, 13]; 

When the array type is implied by context, the type identifier may be 
omitted: 

triplet <- [11, 12, 13]; 

The function ALL may also be used during initialization ( only when the array 
type is implied by context): 

Matrix3by4: TYPE = ARRAY[0..3) OF ARRAY [0..4) OF CARDINAL; 
allOnes: Matrix3by4 <- ALL[ALL[1]]; 

You can, of course, access individual components of an array: 

triplet[l] <r 82; 

al 10nes[2][3] «- 82; - 2nd row, 3rd column 
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Array Equivalence and Conformance 

Two array types are equivalent if both their index types and their 
component types are equivalent and if they are both packed or both 
unpacked. 

Conformance: 

An array type freely conforms to another if the component type of the first 
freely conforms to that of the second, the index types are equivalent, and 
they are both packed or both unpacked. Packed arrays with non- 
equivalent types do not freely conform. 

Examples: 

IndexTyp: TYPE = [0. .10); 

ArrayTypel: TYPE = ARRAY IndexTyp OF INTEGER; 
ArrayType2; TYPE = ARRAY [0..10) OF INTEGER; 
Numbers: TYPE = PACKED ARRAY [0..10) OF INTEGER; 

ArrayTypel and ArrayType2 are equivalent. 



Getting Started in Mesa 



Mesa Language Class - February, 1988 



1-35 



Records 

Most records are declared with named field-lists: 

MilitaryTime: TYPE = REC0RD[ 
hrs: [0..24), 
mins: [0..60) ]; 

oldTime, newTime: MilitaryTime; 

You can assign parts of the record field by field: 

oldTime. hrs «■ 8; 
oldTime. mins «- 0; 

Or you can assign the entire record with either a keyword or positional 
constructor: 

oldTime «- [mins:0, hrs: 8]; - Fields may be in any order 
o 1 d T i me «- [ 8 , 0 ] ; - Fields must be in order 

Sometimes records are declared with unnamed field-lists: 

RecType: TYPE = RECORD [CARDINAL, CARDINAL]; 

Only a positional constructor can be used with such records. 
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Default Field Values 

When a record type is declared, default values may be specified for each 
field. Fields in a record constructor may be voided, elided, or omitted: 

Rec: TYPE = RECORD [ 
vl: CARDINAL, 
v2: CARDINAL <- 3]; 

rec : Rec ; 

rec <- [ v 1 : 4 , v 2 : 5 ] ; - v2 gets 5 (overrides default) 
rec«-[vl:4]; ~v2 is omitted, so v2 gets 3 

rec «- [vl:4, v2: ~\\~\/2ise{ided,sov2gets3 
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Record Extractors 

Extractors are used to "explode" record objects and assign their 
components to individual variables in a single statement: 

MonthName: TYPE - {Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, 
Oct, Nov, Dec}; 

Date: TYPE = REC0RD[ 
day: [1..31]; 
month: MonthName, 
year: [1900 .. 2000 )] ; 

birthDay: Date; 

dd: [1..31]; 
mm: MonthName; 
yy: [1900 .. 2000 ) ; 

birthDay «- [8, Aug, 1959]; 

[dd, mm, yy] <- birthDay; 

[dd, , yy] <- birthDay; 

[dd, mm, yy] «- Date[25, Apr, 1943]; 

[month:mm, day:dd, year:yy] «- birthDay; 

The type of a constructor must be explicitly stated when an extractor is on 
the leftside. 
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Record Extractors 



A value with a single-component record type may be converted 
automatically to a value with the type of that component. 

j: INTEGER; 

k: REC0RD[i: INTEGER <- 5]; 
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Record Conformance 

Every appearance of a record constructor creates a new type that is not 
equivalent to, and does not conform to, any other record type. 

RecTypel: TYPE = REC0RD[a , b : INTEGER] ; 
reel: RecTypel; 

RecType2: TYPE * RECORD[a , b : INTEGER]; 
rec2: RecType2; 

rec3: REC0RD[a,b: INTEGER] ; 
rec4: REC0RD[a, b : INTEGER] ; 

The record variables red, rec2, rec3, and rec4 all have different, non- 
conforming types. None of these can be assigned to any of the others. 
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Pointers 

POINTERS are one word objects that, therefore, reference objects in the 
MDS in virtual memory. The MDS is 64K words of virtual memory in which 
system data structures and all local frames of executing processes reside. 

LONG POINTERS are two word objects that, therefore, reference objects 
outside the MDS. Most dynamically allocated objects are outside the MDS. 
For generality, LONG POINTERS are often used to reference objects in the 
MDS, as well. 

In general, use LONG POINTERS. 

intPtr: POINTER TO INTEGER; 
boolPtr: LONG POINTER TO BOOLEAN; 
intPtr <- NIL; 

Note: NIL is a Mesa reserved word that conforms to any POINTER or LONG 
POINTER type. It denotes that the pointer value has no valid referent. 

Also, In Post Pilot 14.0 releases, global frames do not reside in the MDS (as 
they did previously). Therefore (short) POINTERS can not be used to 
indirectly access global variables. 
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Pointer Dereferencing 

Referents of pointers can be obtained with the operator f . Pointer values 
can be generated from objects with the operator @. 

AgeRange: TYPE = [21. .150); 
SexValues: TYPE = {male, female}; 
PartyValues: TYPE = {democratic, republican}; 

Person: TYPE = REC0RD[ 
age: AgeRange, 
sex: SexValues, 
party: PartyValues]; 

candidatel , candidate2: Person; 

winner, loser: LONG POINTER TO Person «- NIL; 

loser <- @candidatel; - loser gets the address of candidatel 
winner <- @candidate2; 
winnert.age <- 45; 

winner.age^45; - Mesa automatic dereferencing 
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Pointer Conformance and Equivalence 

Two pointer types are equivalent if their reference types are equivalent and 
if they are both long pointers or both short pointers: 

IntPtrType: TYPE - LONG POINTER TO INTEGER; 

a: IntPtrType; 

b: LONG POINTER TO INTEGER; 

Here, a and b have the same type. 
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Dangling Pointers 

Be careful to avoid dangling pointers to local storage: 
pointerl, pointer2: LONG POINTER TO INTEGER; 

• • • 

RiskyProc: PROCEDURE[i: INTEGER] = { 
local: INTEGER; 

• « • 

pointerl <- @i; - the storage for i and local exists only for 
p o i n t e r 2 <-@ 1 o c a 1 ; -the life of this procedure 

■ • • 

RETURN ; - all local storage is released 

}; 

After the procedure, RiskyProc returns, pointerl and pointer2 will point to 
variables that no longer exist. 
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Assignment Statements and Expressions 

The type of the < rights ide> must conform to the type of the <lef tside>: 
<leftside> <- <rightside>; 

a «- b + c; 

A variable may also be assigned using an assignment expression. The type 
and value of an assignment expression (multiple assignment statements) is 
thetypeand value of the <l eftside>: 

a <- b «- c <- 4; -- a, b, and call get 4 
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IF Statements 



Standard If-Then statements: 

IF <boolean expression> THEN 
<statement> ; 

Example: 

IF x > 5 THEN 
x <- x * 2; 



Standard If-Then-Else statements: 

IF <boolean expression> THEN 

<statementl> 
ELSE 

<statement2> ; 

Example: 

IF x > 5 THEN 

x <- x * 2 
ELSE 

y <- y + 200; 



Getting Started in Mesa 



Mesa Language Class - February, 1 988 



1-46 



IF Expressions 



The IF Expression syntax is similar to that of an IF Statement. There are two 
differences: 

1) The clauses contain expressions, not statements, and 

2) an IF Expression must have an ELSE clause. 



IF <boo1ean expression> THEN 

<expression> 
ELSE 

<expression> 

Example: 



x <- 



IF x > 5 THEN 

x*2 
ELSE 

x + 200 
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SELECT Statements 

SELECT statements are similar to Pascal CASE statements. 

SELECT <expression> FROM 

<expressionl> => <statementl>; 
<expression2> => <statement2> ; 
<expressiori3> -> <statement3> ; 

<expressionN> => <statementN> ; 
ENDCASE => <statement>; 

Example: 

i: CARDINAL; 

SELECT i FROM 

0 => i «- i + 1; 
<3 => { j i ; i <- i 
= 5 => i 0; 
ENDCASE => i <- 2 ; 



-• 1 } ; - / = 7 or i = 2 

- / =5 

- none of the above 
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Select Statements 

A single SELECT arm may specify more than one test in one arm. 
Example: 

i,j,k: CARDINAL; 

SELECT i*j+k FROM 

1, IN[7..10] => <stmtl>; -values: 1,7,8,9,10 

2, 5, >10 => <stmt2>; -values: 2,5,11,12, ... 
ENDCASE ; - no arm for endcase 
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SELECT Expressions 

SELECT expressions can be used in the same way as IF expressions (with the 
same restrictions): 

SELECT <expression> FROM 

<expressionl> => <resu1t expressions , 

<expression2> => <result expression2>, 

<expression3> -> <result expression3> , 

• o • 

<expressionN> -> <result expressionN> , 
ENDCASE -> <resu1t expression> 

Example: 

pt: INTEGER; - Point on a line 
1 o , hi: INTEGER; - Bounds for a line 

• • • 

PointPosition : TYPE = {leftMargin, rightMargin, inside, 

outside, degenerate}; 
position: PointPosition; 



SELECT pt FROM 




IN (To.. hi) => inside, 




NOT IN [To.. hi] => outside, 




< hi => leftMargin, -- = 


lo but #hi 


> lo => rightMargin , = 


hi but #lo 


ENDCASE => degenerate -- = 


hand =hi~ 
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Blocks 

The general structure of a compound statement is: 

BEGIN 

<0penCl ause> 
<Enab1 eCl ause> 

<Decl arationSeries> 
<StatementSeries> 
<Exi tsCl ause> 

END; 

Everything but the <StatementSeries> is optional. 

An <0penCl ause> allows more convenient reference to the fields of a record 
and symbols in an interface. 

An <EnableClause> is used with signals. 

The <Decl arationSeries> allows you to declare variables at the beginning 
of any block: 

IF To > hi THEN 
BEGIN 

temp: INTEGER 4- To; 
To <- hi; 
hi «- temp; 
END; 
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GOTO Statements 

A series of labeled statements may be written immediately preceding the 
END in a block. One can jump to these statements from within the block 
using a GOTO statement: 

IF . . . THEN 
BEGIN 

IF ... THEN GOTO useDefault; 
IF ... THEN GOTO f i 1 elsDef au 1 t ; 
IF . . . THEN GOTO newFile; 

• • « 

EXITS 

useDefault, f i 1 elsDef aul t => {...}; 
newFile => pages *- 0; 
END; 

Restrictions: 

1) A GOTO may only jump forward in a program, never backward, and 

2) A GOTO may only jump out of a block, never into one. 
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Loop Statements 

The basic structure of a loop is shown below: 

<LoopControl> DO 
<0penC1 ause> 
<Enabl eCl ause> 

<Dec1 arationSeries> 
<StatementSeries> 
< Loop Ex i tsCI ause> 
ENDLOOP; 

The loop control can either be a form of conditional control or iterative 
control or both. 
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Conditional Control 

Either a WHILE loop or UNTIL loop can be used in loop control: 

WHILE <boolean expression> DO 
<statement> ; 
<statement> ; 

ENDLOOP; 

UNTIL <boo1ean expression> DO 
<statement> ; 
<statement>; 

• • • 

ENDLOOP; 

Examples: 

■1 «- 1; 

WHILE i < 10 DO 
i <- i + 1; 
ENDLOOP; 

1 <- 1; 

UNTIL i >= 10 DO 
ENDLOOP; 
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Iterative Control Repetition 

With repetition, a loop range specifies how many times the loop body is to 
be executed: 

THROUGH <1ooprange> DO 
<statement> 
ENDLOOP; 

Example: 

THROUGH [1. .100] DO 

ENDLOOP; 

A loop range can have any element type or any subrange of LONG 
CARDINAL or LONG INTEGER. This is the one time that a subrange of a long 
numeric is allowed. 

Repetition and a conditional test may be combined: 
THROUGH [low.. high] WHILE 1 i nelsConnected DO 

ENDLOOP; 

Normal termination occurs after (high - low + 1) iterations; conditional 
termination can occur sooner if 1 inelsConnected is FALSE prior to some 
iteration. 
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Iterative Control Iteration 

Iteration is very similar to a FOR loop in Pascal : 

FOR <preDecl aredCont rol Van' abl e> IN <1ooprange> DO 

• • ♦ 

ENDLOOP; 
Example: 

FOR i IN [1. .length) DO 

ENDLOOP; 

The control variable can be declared at the point it's used : 
FOR j: CARDINAL DECREASING IN [0..256) DO 

• * • 

ENDLOOP; 

Iteration and a condition test may also be combined. 
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Iterative Control - Assignation 

With assignation, a control variable is given an initial expression and a next 
expression after each execution of the block. A condition test should be 
included to provide loop termination: 

FOR <var> <in1tial expr>, <next expr> DO 

• • • 

ENDLOOP; 
Example: 

NodePtr: TYPE = LONG POINTER TO Node; 
node: NodePtr; 
head; NodePtr; 
Node: TYPE = REC0RD[ 

"MstValue: CARDINAL, 

next: NodePtr]; 

• • • 

FOR node <- head, node. next UNTIL node - NIL DO 

• • « 

ENDLOOP; 
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GOTOs, LOOPs f and EXITs 

A loop may be forcibly terminated by a GOTO or an EXIT. The LoopExitsClause 
serves the same purpose as the ExitsClause in a block. There are 4 
differences. 

(1) The LoopExitsClause is bracketed by REPEAT and ENDLOOP instead of 
EXITS and END. 

(2) The LoopExitsClause may contain a final statement labeled with the 
keyword finished; this statement is executed if the loop terminates 
normally or conditionally, but not if it is forcibly terminated by an exit 
or GOTO statement. 

(3) There is a special case of the more general GOTO, called EXIT, which 
simply terminates a loop forcibly without giving control to any 
statement in the LoopExitsClause. 

(4) There is another kind of GOTO statement, called LOOP, which does not 
terminate the loop but skips the remainder of the loop body in the 
current iteration and continues with the next iteration. 
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GOTOs, LOOPs, and EXITs Examples 

(1)&(2): FOR 1 IN [0. .nEntries) DO 

If a[i] = x THEN GOTO found; 
REPEAT - REPEAT is not indicative 

found => old <- TRUE; 
FINISHED -> { 

a[i *■ nEntries] <- x; 
nEntries «■ nEntries + 1; 
old <- FALSE }; 
ENDLOOP; 



(3): DO 

• • • 

IF ... THEN EXIT; 

• • . 
ENDLOOP; 



(4): stuff: ARRAY[0. . 100) OF PotentiallylnterestingData; 

FOR i: CARDINAL IN [0..100) DO 

• * • 

IF NOT Interesting[stuff [i]] THEN LOOP; 

• • * 

ENDLOOP; 
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Outline 

1. Getting Started in Mesa (cont'd) 

g. PROCEDURES 

h. Additional Data Types, Extensions 

i. Strings 

ii. Variant Records 

iii. Array Descriptors 

iv. Base and Relative Pointers 



Getting Started in Mesa 



Mesa Language Class ~ May, 1988 



1-60 



Procedures 

The definition of a procedure provides a name for a function or action: 

<name>: PROCEDURE ^argument record> 
RETURNS <resu1t record> = 
BEGIN 

END; 
Examples: 

NewNumbe r : PROCEDURE RETURNS [x : CARDINAL] = 
BEGIN 

END; 

Gcd: PROCEDURE[m , n ; INTEGER] RETURNS [gcd: CARDINAL] = 
BEGIN 

r: INTEGER; 
UNTIL n = 0 DO 

r *• m MOD n ; 

m <- n ; 

n r; 

ENDLOOP; 
RETURN[ABS[m]]; 
END; 
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Procedures - Passing Arguments 

In procedure call, the arguments are packaged into a record. Therefore, a 
procedure call may use all the syntax for record constructors in passing 
arguments. Arguments may be specified using either keyword or positional 
notation. Arguments not explicitly specified may be supplied by default. The 
following calls of Gcd are equivalent: 

Gcd[x+l,y]; Gcd[m: x+1 , n :y] ; Gcd[n :y ,m: x+1] ; 

All parameters are passed by value. 

If the procedure returns no results, the procedure is written as a normal 
statement: 

... code fragment 
x <- x + 1; 
D1splay[x]; 

Note: A procedure call that passes no arguments should include empty 
brackets to avoid confusion with procedure variables (explained later). 

x «- SomeProc[]; 
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Procedures - Results 

If the procedure returns results, the results are obtained with an extractor: 

Exampl eProc : PROCEDURE RETURNS [a , b : INTEGER] = 
BEGIN 

• • • 

END; 

x,y: INTEGER; 

... -- code fragment 

[x,y] <- Exampl eProc[] ; 

[b:y,a:x] «- Exampl eProc[] ; 

If the procedure returns only one result, the extractor is not necessary: 

gcd: CARDINAL; 

g c d «- G c d [ m , n ] ; ~ Calling the procedure declared earlier 
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Return Statements 

A RETURN statement may be used anywhere in the procedure to terminate 
execution of the current procedure activation: 

ReturnExample: PROC [option : [1 4]] RETURNS [a, b , c : INTEGER] = { 
a «- b <- c <- 0; 
SELECT option FROM 

1 => RETURN [a:l, b:2, c:3]; - explicit RETURNS 

2 => RETURN [1,2,3]; 

3 => RETURN ; - returns the current values of a, b, c 
ENDCASE -> b «- 4; 

c +• 9; 

}; -Implicit RETURN 
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Scoping Rules for Procedures 

Mesa uses static scoping rules; each block defines a new scope: 
SomeModule: PROGRAM = 



BEGIN 

x,y: INTEGER; 

• « • 

OuterProc: PROCEDURE = 



BEGIN 


x: BOOLEAN; 


Local Proc: PROCEDURE 




[parml: CARDINAL] RETURNS[parm2 : CARDINAL] = 






BEGIN 






x: CHARACTER; 






END; 




END; 



• « • 

END. 
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Procedure Types and Variables 

Procedures are actually types that are similar to pointers. 

TrlgProc: TYPE = PROCEDURE[x: REAL] RETURNS[REAL] ; Procedure TYPE 

ArcSin: TrigProc ■ BEGIN ... END; - Procedure Constant 

ArcTan: TrigProc s BEGIN ... END; - Procedure Constant 

FooBar: TrigProc; ~ Procedure Variable 

• • • 

FooBar «- A rcS i n ; — this is not making a call to A rcS i n, but rather assigning what 

- the procedure A rcS i n is equal to to the procedure F u n c 
x <- F o o B a r [ x ] ; ~ sin ce F u n c has meaning, it is valid to make a call to it 
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Procedure Equivalence and Conformance 

Equivalence and conformance of procedure types are defined in terms of 
relations between fields of their parameter lists and result lists. 

Two procedure types are equivalent if, for each pair of fields, the names are 
identical (or both are unnamed), the types are equivalent, and both default 
options are empty. 

One field is compatible with another if the names are identical or if either is 
unnamed, and if the types are equivalent. A procedure type conforms freely 
to another if all corresponding fields are compatible. 

Example: 

Handle: TYPE = LONG POINTER TO Person; 
SignedNumber: TYPE = INTEGER; 
Int: TYPE = INTEGER; 

ProcA: PROCEDURE[h : Handle, v: SignedNumber]; 

ProcB: PROCEDURE[h: Handle, v:Int]; 

ProcC: PROCEDURE[LONG POINTER TO Person, INTEGER]; 

ProcA, ProcB, and ProcC all conform to each other. 
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Inline Procedures 

INLINE procedures can be used to eliminate the overhead of a procedure call 
and return usually at the cost of a longer object program. 

If the attribute INLINE appears before the body in the declaration of a 
procedure, the call of that procedure is replaced by an inline expansion, a 
modified copy of the procedure's body: 

Proc: PROCEDURE[v: INTEGER] RETURNS [INTEGER] = INLINE 
BEGIN 

RETURN[v*v + 3*v + 1]; 
END; 

See the rules in the MLM for applying the INLINE attribute. 
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Strings 

In Mesa, a STRING represents a finite, possibly empty series of characters. 
Mesa contains the following predefined types: 

STRING: TYPE = POINTER TO StringBody; 
StringBody: TYPE = MACHINE DEPENDENT REC0RD[ 

length: CARDINAL, 

maxlength: CARDINAL, -readonly 

text: PACKED ARRAY [0..0) OF CHARACTER]; 

Where: 

text is a PACKED ARRAY of characters 

maxlength is the maximum numbers of characters that text can hold 
length is the number of characters currently in text 

String variables can be declared and initialized two ways. 

1) to specify the maxlength of the string, but not its contents 

2) to assign a string literal to the variable 

Examples: 

Local Proc: PROC = { 

currentLine: STRING «- [256]; - no value set here for the characters 
whatWasThat: STRING = " E h ? " L ; string literal 
... - cu rrentLi ne gets a value somehow 

IF currentLine[2] = 'R THEN HelpaLot[]; 

can reference a specific character in the string 

• • • 

}; 
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Long Strings and String Operators 

A LONG STRING is predefined as: 

LONG STRING: TYPE = LONG POINTER TO StringBody; 

Note: A LONG STRING does not mean that it can hold more characters than a 
STRING, it means that it is a LONG POINTER to a StringBody. The difference is 
that STRINGS are short pointers and therefore they reference into the MDS, 
whereas LONG STRINGS can access storage outside the MDS. 

Also, in Post Pilot 14.0 releases, a string literal in the global frame can be 
assigned only to a LONG STRING, since the storage for global frames does 
not come from the MDS as in earlier releases. 

In general, LONG STRINGS should be used instead of STRINGS. 

Since STRINGS and LONG STRINGS are essentially pointers, the fundamental 
pointer operations =, and # can be used with STRINGS and LONG 
STRINGS. 
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Variant Records 

Variant records contain a set of common fields and a variant portion with a 
specified set of different possible interpretations. In Mesa, there are 4 
different forms of the tag and they represent: 

an actual tag with an explicit enumerated type 

an actual tag implicitly defined 
~ a computed tag 
-an OVERLAID tag 
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Variant Record Examples 

Service: TYPE - {savings, checking}; 

Account: TYPE = REC0RD[ - actual tag with explicit type 

balance: REAL, 

specifics: SELECT variantType: Service FROM 
savings => [intRate: REAL, term: [30.. 365]], 
checking => [charges: REAL], 
ENDCASE]; 

Account: TYPE = REC0RD[ - actual tag with implicitly defined type 

balance: REAL, 

specifics: SELECT variantType:* FROM 

savings => [intRate: REAL, term: [30.. 365]], 

checking => [charges: REAL], 

ENDCASE]; 

Account: TYPE = REC0RD[ -computed tag 

balance: REAL, 

specif ics:SELECT COMPUTED {savi ngs , c heck i ng} FROM 
savings => [intRate: REAL, term: [30.. 365]], 
checking => [charges: REAL], 
ENDCASE]; 

Account: TYPE = REC0RD[ -overlaid tag 

balance: REAL, 

specifics: SELECT OVERLAID * FROM 

savings => [intRate: REAL, term: [30.. 365]], 

checking -> [charges: REAL], 

ENDCASE]; 

* is used to indicate that the type of an actual tag is being defined implicitly 
by the set of adjectives naming the variants in the tag's variant part. 
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Variant Record Variables 

Variables that are variant records can either have bound variant types or 
unbound variant types: 

r: Account; - unbound variant type 

rSavings: savings Account; - bound variant type 
rChecking: checking Account; -- bound variant type 
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Variant Part, Tag Access 

The variant part of a record and its tag can only be assigned with a 
constructor. 

r <- [balance: 100.0, specifics: checking [charges: 0.5]]; 

r <- [100.0, savings[7.0,35]]; 
Assigning the variant part of a record has the side effect of assigning the tag. 
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Accessing Components of Variants 



When a record is a bound variant, components of its variant part may be 
accessed as if they were common components: 

rSavings . intRate <- 8.9; 

rChecki ng . charges «- 1.0; 

With unbound variants, a generalized SELECT statement must be used for 
actual tags: 



checking => charges <- 1.0; 
ENDCASE; 

For computed and overlaid tags, an expression must be supplied yielding a 
tag value: 

WITH r SELECT (IF ... THEN savings ELSE checking) FROM 
savi ngs => ... 
checking => ... 
ENDCASE; 



WITH r SELECT v 




ype FROM 



savings => { 



intRate «- 8.8; 
term «- 90; 

}: 
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Accessing Components of Variants 

For overlaid tags, a field in a variant that appears in no other variant can be 
referenced directly: 

r. IntRate «- 8.8; 
r. charges «- 1.0; 
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Array Descriptors 



An array descriptor describes the location and length of an array. There are 
three operators that are relevant to array descriptors. 

LENGTH[<an array>] yields the number of array elements 

B ASE [ < an array > ] - yields a pointer value for locating the first element 

DESCRIPTOR[<an array>] -- yields an array descriptor (record of base and length) 

Example: 

history: DESCRIPTOR FOR ARRAY OF CARDINAL; 
numbers: ARRAY [0..1000) OF CARDINAL; 
history <- DESCRIPTOR[numbers] ; 

Descriptors historically were used for dynamic arrays and are present mainly 
for backward compatibility. They are used for parameter passing now. 
Sequences (described later) are now used for dynamic arrays instead and are 
the recommended method. 
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Base and Relative Pointers 

Relative pointers require the addition of a base pointer to obtain an 
absolute pointer. This allows data structures with internal references that 
are independent of memory location. 

They are used with movable storage areas called ZONEs. Consult the MLM 
and the PPM for details. 
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The Debugger 
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The Debugger 

Some of the material in this section overlaps the material covered in the XDE 
tutorials that you should have already completed. This is desirable because: 

1) some students will not have gone through the tutorials, thus making 
this lab their first exposure to the debugger. 

2) the extra practice can't hurt. 
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CoPilot vs. Sword 

There are two different debuggers depending on what version of software 
you are running. If you are running a pre 12.3 release, then you will be using 
the CoPilot debugger, which is built into the CoPilot bootfile. 

If you are running at 12.3, then you have the option of using the built-in 
CoPilot debugger or using the new SWorD debugger, which is a separate 
application that must be run on a Tajo bootfile. 

CoPilot will not be available for versions newer than 1 2.3. 

The information in this lecture applies to both the CoPilot debugger and to 
SWorD. 
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The Debugger 

• Interactive, sourceline-level 

• Resides on an XDE volume., 

The debugger need not reside on the same machine as the client (e.g. 
Remote debugging). 

• Allows inspection of run-time stack, variables, processes, etc.; variables 
can be re-assigned, individual procedures can be called. 

• What will be covered: 

• Common command usage 

• What the programmer sees 

• What won't be covered : 

• Low-level and other operating system-related details 
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Getting the Debugger Window 



If you are using the CoPilot debugger, then you do not run anything special. 
The Copilot debugger is built into the CoPilot bootfile. Look for a window 
labelled Debug.log, which when opened looks like this: 




If you are using the Sword debugger, then you must run Sword. bed. Sword 
requires a Tajo bootfile. Look for a window labelled Debug.log, which when 
opened looks like this: 



Local World (Debug. Iog2) 



go: {proceed, abort Kill, screen, start} client: {local} destroy! 

read: {} write: {} processes configs attach: {source, symbols} 
source! findModulei rep?! showType! type&bits! options', 
break: {set clear, clearall, list, attachCond, attachKey} watch: {off} 



Local World (Debug, log2) 
Interpreter 

> 



Sword can have multiple windows. To get another window: 

1) In 12.3, execute the "New Interpreter" command in the stack of root 
menus, or 

2) In 14.0, execute the "Another!" command in the Sword form 
subwindow. 
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Reasons for Entering the Debugger 

• Interrupt 

• Breakpoint 

• Map Log 

• Error 

• Address Fault 

• Uncaught Signal 
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Commands for When in Doubt 

• {zero or more characters} ?: 

Displays all the commands that begin with the specified characters. 

• the DELETE key: 

Allows you to cancel any command before it's been invoked. 

• the STOP key: 

Allows you to cancel any command during its execution. 
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Commands to Inspect Modules 

• Module Context: 

Sets the module context to the user-specified module. The variables 
and procedures in the current module are recognized. 

• Display Stack: 

Displays the top of the run-time stack, which is the procedure 
currently being executed. Also puts you in a subcommand mode to 
learn more about each element on the stack. 
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Subcommand Mode (after a Display Stack) 

• source: 

displays the source line where the debugger was invoked and loads 
the file in a window if it isn't loaded already. The source file is 
scrolled so that the line in question is in view. 

• variables: 

displays the local variables and the parameters for that procedure 

• global variables 

displays the global variables for that module 

displays the parameters for that procedure 

• next: 

displays the next procedure call on the run-time stack 

• back: 

goes back up the stack (reverse of next) 

• guit (or the DELETE key): 

gets you out of the subcommand mode 
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Commands to Inspect Processes 

• List Processes (also available in the Sword FormSW): 

Lists the currently active processes in the client volume. 

• SEt Process Context: 

Sets the current process context to the user-specified process. The 
call stack for that process is recognized. 
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Commands Related to Swapping 

• Proceed (also available in the Sword FormSW): 

Continues execution of the program by going back to the client 
volume and executing from the point where the debugger was 
invoked. 

• Quit (also available in the Sword FormSW as 'abort'): 

Raises the signal ABORTED in the process that entered the 
debugger, which usually results in that process being deleted. 

• Userscreen (also available in the Sword FormSW as 'screen'): 

Applies only to world-swap debugging. Displays the screen bitmap 
of the client volume for 20 seconds, or less if the "STOP" key is 
toggled. 

• ReDisplay swap reason : 

Redisplays the reason why the debugger was called. Sometimes the 
user can give the debugger more, information and then redisplay 
the swap reason to learn more about why the swap occurred. 
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Setting Breakpoints 

• Break Entry procedure: 

Sets a breakpoint at the point of entry to a procedure 

• Break Xit procedure: 

Sets a breakpoint at the point of exit of a procedure. 

• To set a breakpoint in source other than at the beginning or end of a 
procedure, load the source file into a window, make a selection on the 
line where the breakpoint is to be set. Then, 

1) with Sword hit the "set" command of the "break:" enumerated 
within the FormSW. 

2) With CoPilot, click "Break" in the window menu. 

A breakpoint will then be set at the beginning of the statement in 
which the selection was made. 
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Some Other Breakpoint Commands 

• List Breaks (also available in the Sword FormSW): 

Lists all the breakpoints that are currently set. 

• Clear All Breaks (also available in the Sword FormSW): 

Clears all currently set breakpoints. 

• Clear Break # (also available in the Sword FormSW): 

Clears the break that you specify by number. 

• Attach Condition (also available in the Sword FormSW): 

Attaches a boolean condition that must be TRUE in order for the 
break to occur. 

• Attach Keystrokes (also available in the Sword FormSW): 

Attaches a user-supplied string of characters to be entered into the 
debugger when the associated breakpoint is executed. 
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Using the Interpreter Mode 

• Interpreter mode handles a subset of Mesa. 

• In the interpeter mode # you can display and re-assign variables (simple or 
complex), dereference pointers, call procedures, and convert types. 

• Interpreter mode is invoked by typing a space character at the beginning 
of a line. After typing the space, you can type a variable name to inspect 
that variable. 

• To dereference a pointer variable, type the variable name followed by an 
up-arrow ("foot"). To dereference a pointer to a pointer, type the 
variable name followed by 2 up-arrows ("f ooi-r"). 
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Setting the Options 

The Debugger Options window allows you to change the default format 
that the debugger uses in displaying values of variables as well as specify (for 
Sword only) whether or not a particular kind of event is handled locally. 

Invoke the options! command in the FormSW to bring up the Options 
window. 

There are four booleans at the bottom of the window. If a boolean is true 
and the corresponding event occurs, it is handled locally. If a boolean if false 
then the event causes a world-swap. The booleans map to: 

fault = address fault, uncaught = uncaught signal, 

break = breakpoint, calldebug = SHIFT-STOP 



Local World (Debug.log2) 



90: {proceed, abort, kill, screen, start} client: {local} destroy! 
read: {} write: {} processes configs attach: {source, symbols} 

source! fincModule! rep?! showType! type&bits! options! 

break: {set, clear, clear all, list, attachCond, attachKey} watch: {off} 



Local World (Debug. log2) 
Interpreter 



Interpreter Options 



CARDINAL: {octal, 
Apply! POINTIER: {_ 
Abort! RELATIVE: {_ 
Array elements = 10 
filter: 



L 



decimal 



octal 



octal 



, hex} signed INTEGER: {octal, hex ) 
decimal, hex} PROCESS: I' NMfcil . decimal, hex} 
decimal, hex} UNSPECIFIED: i fcMfell . decimal, hex} 
String length =* 150 



processes configs 



Be sure to invoke Apply! to have the changes take effect or Abort! to restore 
them to the previous options. (Do not just tiny or deactivate the options 
window.) 
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Show Type 

Show Type allows you to find out the type of various procedures and 
variables. It operates on the current selection (anywhere on the screen). The 
format must be: 

InterfaceName.symbolName 

If only the Interface name is selected, then all of the types in that file are 
displayed. 



Local World (Debug. loq2) 



go: {proceed, abort Kill, screen, start} client: {local} destroy! 

read: {} write: {} processes configs attach: {source, symbols} 

soiree! fincModule! rep?! showType! typefcbits! options! 
break: {set, clear, clearall, list, attachConcfVattachKey} watch: {off} 



Local World (Debug. log2) 
Interpreter 

> 

Exec.AddCommand: PROCEDURE [name: LONG STRING, proc: Exec.ExecProc, help: 
Exec.ExecProc * NIL, unload: Exec.ExecProc * Exec.DefaultUnloadProc, clientData: 
LONG POINTER + NIL]j 



File: <CoPilot>WD>FactorialTdolBlmpl.mesa 




Create OPos Edit Load Empty Save Time Store Reset Split Watch Destroy 




D 

All! 5! RS! «. SR! R! «: 




n 

CreateFactorialTool: PROCEDURE = { 
UVJJi'fM.IL'Jli l iMW ,, FactorialTool.^ ,, L. NoOp, NIL, Unload]; 
wh <* Tool. Create [ 
makeS WsProc: MakeSWs, initialState: default, 
clientTransition: ClientTransition, name: "Factorial TooT'L]; 
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Processes Boolean (in Sword Only) 

Turning on the processes boolean in the Sword FormSW creates a proceses 
subwindow. This subwindow contains processes, call stacks, and local 
variables. You can zoom or close a particular line by selecting the cross at the 
head of the line. Zooming displays more detail; for instance, zooming a stack 
frame line displays the local variables of the stack frame. 



Local World (Debug. log2) 




go: {proceed, abort kill, screen, start} client: {local} destroy! 
read: O write: O ViiMw'i: confios attach: [source, symbols) 
soiree! findModule! rep?! showType! type&oits! options! 
break: {set, clear, clearall, list, attachCond, attachKey} watch: {off} 




. □ 

x PSB: 53B, waiting CV, L: 4570546*, PC: 18936 (in TTYSWsA, G: 431674B*) 
x PSB: 54B, waiting CV, L: 40601 OB*, PC: 18936 (in TTYSWsA, G: 4316746*) 
x PSB: 55B*, waiting CV, L: 4S5304B*, PC: 2896 (in ITInstall, G: S17414B*) 
x PSB: 56B, waiting CV, L: 4051706*, PC: 18936 (in TTYSWsA, G: 431674B*) 
x No symbols for L: 4051 70B*, PC: 18936 (in TTYSWsA, G: 431674B*) 
x No Variables! 

x No symbols for L: 40641 0B*, PC: 204 (in TTYImpl, G: 4402446*) 
x PSB: 66B, waiting CV, L: 4561 14B*, PC: 89 (in TTYImpl, G: 440244B*} 
x PSB: 67B, waiting CV, L: 4142546*, PC: 89 (in TTYImpl, G: 4402446*) 
x PSB: 117B, waiting CV, L: 403040B*, PC: 389 (in Processes, G: 417674B*) 
x No symbols for L: 403040B*, PC: 389 (in Processes, G: 417674B*) 
x No symbols for L: 405664B*, PC: 268 (in ClockToollmpl, G: 52331 46*) 
x PSB: 124B, waiting CV, L: 455354B*, PC: 18936 (in TTYSWsA, G: 431674B*) 




□ 

Local World (Debug. 1og2) 
Interpreter 

> 
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Configs Boolean (in Sword Only) 

Turning on the configs boolean creates a configs subwindow. This 
subwindow contains configurations, modules, and global variables. You can 
zoom or close a particular line by selecting the cross at the head of the line. 
Zooming a configuration line, for instance, displays the nested 
configurations and modules. 



LocalWorld (Debuq.log2) 




go: {proceed, abort Kill, screen, start} client: {local} destroy! 
read: {} write: {} processes BWiUf>!« attach: {source, symbols} 

rr pi f irvUrwiilfa' ren" sfwwfTvw*' t'vne&hita' mtinrK' 

break: {set, clear, clearall, list attachCond, attachKey} watch: {off} 

: — a 




x Activity 
x Mail Tool 
x RemoteExec 
x AddHintMenus 
x FileTool2 

x FileToollmplA, G:S11270B No symbols, 
x No Variables! 

x FileToollmplB, G:S115GQB No symbols. 

x FileToollmplC, G:511564B No symbols, 
x Sword 
x ExpandType 
x OriginalPosition 
x Source"!" i me 




, n 

Local World (Debug. log2) 
Interpreter 

> 
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PROPS-STOP 

Sometimes your machine will "hang", especially when you are locally 
debugging some program and it crashes. PROPS-STOP is a special command 
that is built into 12.3 (and later) Tajo bootfiles. This will create a new notifier 
to let you continue what you were doing. 

PROPS-STOP will usually work when a particular operation is hung but not 
when the entire workstation is hung. (Look at the clock to see if everything is 
hung.) When PROPS-STOP does not work, you will have to re-boot. 

CoPilot bootfiles do not have this feature. 
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Summary 

This lecture was not complete coverage of all commands that are available in 
the debugger. It was meant to give you an introduction to using the 
debuggers. There are many more ways to use the debugger to help you in 
your development work. 

For more information about the CoPilot debugger refer to the Debugger 
chapter in the XDE User's Guide. 

For more information about using Sword, refer to Appendix E of the XDE 
User's Guide. 
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Conformance Among Numerics 



INTEGER, NATURAL, CARDINAL 



conform to INTEGER 



INTEGER, NATURAL, CARDINAL 



conform to CARDINAL 



INTEGER, NATURAL, CARDINAL 



conform to NATURAL 



INTEGER, NATURAL, CARDINAL 
LONG INTEGER, LONG CARDINAL 



conform to LONG INTEGER 



INTEGER, NATURAL, CARDINAL 
LONG INTEGER, LONG CARDINAL 



conform to LONG CARDINAL 



INTEGER, NATURAL, CARDINAL 

LONG INTEGER, LONG CARDIN AL, REAL 



conform to REAL 



Examples: 

i: INTEGER; c: CARDINAL; n: NATURAL; 

li: LONG INTEGER; 1c: LONG CARDINAL; r: REAL; 

-The right side conforms to the leftside. 

i «- c; 
lc <• n; 
c <- i ; 
n c; 
p «■ 1 i ; 
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Conformance Using Range Assertions 

LONG INTEGER, LONG CARDINAL conform to INTEGER 

LONG INTEGER, LONG CARDINAL conform to CARDINAL 

LONG INTEGER, LONG CARDINAL conform to NATURAL 

Examples: 

i: INTEGER; c: CARDINAL 

li: LONG INTEGER; 1c: LONG CARDINAL; 

The right side conforms to the leftside. 
1 <- INTEGERpi]; 
c +• CARDINAL[1 i ] ; 
i 4- INTEGER[1 c] ; 
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Word Length Rules For Expressions (Balancing) 

In determining what type of operation (INTEGER, CARDINAL, LONG 
INTEGER, LONG CARDINAL, REAL) should be performed in an expression, a 
common word length must first be found. 

In general, the operation requiring the fewest automatic type conversions 
will be the one used. So for numerics: 

1. If all (both) operands are short numerics, a short numeric operation 
will be used. 

2. If all (both) operands are long numerics, a long numeric operation will 
be used. 

3. If one operand is a long numeric, the other operand will be 
lengthened and a long operation will be used. 

a. When an INTEGER is lengthened, its inherent type is LONG 
INTEGER. 

b. When a CARDINAL or NATURAL is lengthened, its inherent type is 
LONG INTEGER and LONG CARDINAL. 

4. If one operand is a REAL the other operand is converted and a REAL 
operation is used. 
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Determination of Representation (Balancing) 

Once a common word length is found for an expression, the following rules 
will choose whether a signed (INTEGER, LONG INTEGER) or unsigned 
(CARDINAL, LONG CARDINAL) operation will take place. 

1. If the operands have exactly one common inherent representation, 
the operation defined for that representation is selected (and the 
target representation is ignored). 

2. If the operands have no common inherent representation but the 
target representation is well-defined, the operation yielding that 
representation is chosen. 

3. If the operands have both inherent representations in common, and if 
the target representation is well-defined, The representation of the 
target type selects the operation. 

4. If the operands have both inherent representations in common but 
the target representation is ill defined, the signed operation is 
chosen. 

5. Unary minus converts its argument to a signed representation if 
necessary and produces a signed result. 

If the operands have no representation in comon and the target 
representation is ill-defined, the expression is in error. 
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Type Determination Examples 

1: INTEGER; c : CARDINAL ; n: NATURAL; 
11: LONG INTEGER lc: LONG CARDINAL; 



c «- c + c 




CARDINAL CARDINAL CARDINAL 



CARDINAL 



i <- c + c 




INTEGER CARDINAL CARDINAL 



Length rule: 1 

CARDINAL Si 9 n ru,e: 1 



Length rule: 1 
Sign rule: 1 
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Type Determination Examples 



li <- i + 1 




LONG INTEGER INTEGER INTEGER 




Length rule: 1 
Sign rule: 1 



INTEGER CARDINAL INTEGER 



\ / Length rule: 1 

INTEGER Si 9 n ru,e: 2 
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Type Determination Examples 



LONG 
CARDINAL 



INTEGER and 
CARDINAL 



CARDINAL 



INTEGER and 
CARDINAL 




Length rule: 1 
Sign rule: 3 



IF n + n > 



INTEGER and 
CARDINAL 



INTEGER and 
CARDINAL 



INTEGER 



Length rule: 1 
Sign rule: 4 
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Type Determination Examples 



1c <- c + 1 i 




LONG CARDINAL LONG INTEGER 

CARDINAL 



LONG INTEGER and LONG INTEGER 




Length rule: 3b 



LONG INTEGER 



Sign rule: 1 
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Example of Incorrect Statement 



IF c < 1 THEN . . . 




Length rule: 1 
Sign rule: 



BOOLEAN 



There is no target type; Mesa cannot determine if you want a signed < 
operation or an unsigned < operation. 
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The Long Operator 

Use the LONG operator to force an operand to be lengthened according to 
the previous length rules. 

Examples: 



11 <- i + L0NG[ i ] ; 



LONG INTEGER INTEGER L0NG[ INTEGER] 



INTEGER LONG INTEGER 



LONG 
INTEGER 



Length rule: 3a 
Sign rule: 1 
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Modules: 

Definitions, Programs, and Configurations 
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Outline 

1. Interfaces 

a. What interfaces are all about 

b. Definitions modules 
c Program modules 

i. Clients 

ii. Implementations 
d. Configurations 
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Programming Without Interfaces 

This code can not be shared with any other program. 



--DoLittle.mesa 
DoLittle: PROGRAM = { 

var: CARDINAL; 

var <- 0; 

THROUGH [1. .100] DO 
var <- var + 5; 
ENDL00P; 

}• 



DoLittle.bcd 



Execute: DoLittle.bcd 
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Types of Mesa Modules 

There are two types of Mesa modules: DEFINITIONS and PROGRAM. 

DEFINITIONS and PROGRAM modules are both written in Mesa. They are 
input to the compiler. The output of the compiler is a binary configuration 
description (bed) file. 

When a module is compiled a time stamp (right down to the second) is 
included in the bed file. This time stamp is what differentiates multiple 
versions of the same file. 

A DEFINITIONS module is commonly referred to as an Interface. 
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Overview 



There are three basic pieces to the interface mechanism: 

An interface, which defines an abstraction. 

(An interface is a module of type DEFINITIONS.) 

A client, which uses the facilities defined in the interface. 
(A client is a module of type PROGRAM.) 

An implementation, which provides the facilities defined in the interface. 
(An implementation is a module of type PROGRAM.) 

There can be more than one client of an interface, and the implementation 
is not necessarily a single module. 



Interface: 

.defines procedures 




Client: 

uses the procedures 
from the interface 



Implementation: 

provides the actual code 
for the procedures in the 
interface 
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Definitions Module 

Interfaces (DEFINITIONS modules) generally define the data structures and 
operations for an abstraction. Interfaces contain only declarations - no 
executable code. 

Here is a typical interface module: 

--Exampl e .mesa 

Example: DEFINITIONS = { 

limit: INTEGER = 86; 

Range: TYPE = [-1 imi t . . 1 imi t] ; 

ReadChar: PROCEDURE RETURNS[ i nput : CHARACTER] ; 

WriteChar: PROCEDURE[output : CHARACTER]; 

}• 
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Compile-Time Items and Run-Time Items 

The items in a DEFINITIONS module fall into two classes: 

compile-time items: definitions of TYPEs and constants 

run-time items: definitions of procedures, signals, programs, 

and other variables 

In the example on the previous page, the first two items are compile-time 
items; the two procedures are run-time items. 

Note: In the Mesa Language Manual, compile-time items are referred to as 
non-interface elements, and run-time items are referred to as 
interface elements. 
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Directory Statement 

If any module uses information from an interface, that interface must be 
listed in the module's DIRECTORY clause. The Directory clause is the first 
thing in any module. 

Note: ONLY DEFINITIONS modules are listed in a DIRECTORY clause. 

Example: 

--SomeMoclule.mesa 
DIRECTORY 

Interf acel , 

Interf aceZ . 

Interf ace3 ; 

SomeModule: DEFINITIONS = { 

• • • 

}; 
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USING Clause 



The USING clause is an optional part of the DIRECTORY statement. It is used 
to list the names of all of the items that will be used from the referenced 
interface. A USING clause is not required, though it is recommended. 
Although, if you do have a USING clause, then you must list each and every 
symbol that you want to use from that interface in the USING clause. 

Examples: 

--SomeModul e .mesa 
DIRECTORY 

Interfacel USING Mteml, item2 t item31 ; -- recommended method 



OR: 



--Tab! e .mesa 
DIRECTORY 
Interfacel; 



Modules: Definitions, Programs and Configurations 



Mesa Language Class -- March, 1988 



2-10 



Referencing Items from an Interface 

To reference the item from the interface in the program body, you must put 
the Interface name first then the symbol name (separated by a period), i.e. 
Interface1.item1. 

Example: 

--Simpl e .mesa 

Simple: DEFINITIONS = { 

limit: INTEGER = 86; 

Range: TYPE = [-1 imi t . . 1 imi t] ; 

Pair: TYPE = REC0RD[f i rst , second: Range]; want to use this item 
PairPtr: TYPE = LONG POINTER TO Pair; 



--Table. mesa 
DIRECTORY 

Simple USING fPairl : 

Table: DEFINITIONS = { 
limit: INTEGER = 256; 
Index: TYPE = [0. .limit); 

PairTable: TYPE = ARRAY Index OF Simple. Pair ; 
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Program Modules 

A program module can access the compile-time items from a definitions 
module as easily as a definitions module. 

--Tabl eUser .mesa 
DIRECTORY 

Simple USING rPairl , 

Table USING fPai rTabl el ; 

TableUser: PROGRAM = { 
pair: Simpl e . Pai r ; 
table: Table. Pai rTabl e ; 

• • • 

Note that you must qualify identifiers from definitions modules with the 
name of the DEFINITIONS module. 
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Summary: Using Compile-Time Items 

To be a client of an interface, you need to know the name of the interface 
and the name of the symbols that you want to use from that interface. 

To access compile-time items from an interface, a client module must do 
three things: 

• Include the name of the interface in its DIRECTORY clause. 

• Include the name of the symbol in the USING clause. 

• Reference the symbol as InterfaceName.Symbol. 
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IMPORTS Clause 

The Imports clause lists the Interfaces for which there needs to be an 
implementation supplied from somewhere. For example, procedures (and 
other run-time items) are defined in an interface but are implemented 
elsewhere. The system needs to know that it needs to match up the 
implementation of the procedure with the caller of that procedure. 

The syntax of using run-time items is like that of using compile-time items 
except that you must also include the interface in the IMPORTS list. 

Note: Only DEFINITIONS modules are listed in an IMPORTS clause. 

--IO.mesa 

10: DEFINITIONS = { 

ReadChar: PROCEDURE RETURNS[ input: CHARACTER]; 
ReadLine: PROCEDURE RETURNS[ input: LONG STRING]; 
WriteChar: PROCEDURE[output : CHARACTER]; 
WriteLine: PROCEDURE[output : LONG STRING]; 
}. 



--CopyDri ver.mesa 
DIRECTORY 

10 USING TReadLine. WriteLinel ; 

CopyDriver: PROGRAM IMPORTS 10 = { 
input: LONG STRING <- [256]; 
DO 

input «- IO.ReadLine n ; 

IF input[0] = THEN EXIT; 

10. WriteLine l" input]; 

ENDLOOP; 

}- 
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Summary: Using Run-Time Items 

To access run-time items from an interface, a client module must: 

• Include the name of the interface in its DIRECTORY clause. 

• Include the name of the symbol in the USING clause. 

• Include the name of the interface in its IMPORTS clause. 

• Reference the symbol as InterfaceName.Symbol. 

Note: You do not need to know anything about the implementation of the 
procedures in the interface. You just take on faith that if something is 
advertised in an Interface, you can use it. 
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Compilation Order 

The DIRECTORY clause lists all the interfaces from which you are using 
information. To type-check your program, the compiler must be able to read 
all of the interfaces listed in the DIRECTORY clause. This means that when 
you compile a program, the compiled version of all the interfaces in the 
DIRECTORY clause must be on your local disk. 

--StringCI ient.mesa 
DIRECTORY 

String USING [Equivalent]; 

StringCI ient: PROGRAM IMPORTS String = { 

sameString: BOOLEAN «- Stri ng . Equi val ent[strl , str2]; 

}- 

Thus, to compile StringClient.mesa, you must have the file String. bed on 
your local disk. The compiler will include the time stamp of String. bed in 
StringClient.bcd. If the referenced Interface is not present, the compiler will 
give the message "Can't Open String. bed of 
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What Exactly Do You Need? 

What do you need at compile time and what do you need at run time? This 
topic usually confuses new Mesa programmers. Hopefully this table will 
help. 





Examples 


Examples 




of Interfaces 


of Implementations 




1) System Interface 


1) System Interface Impl 




2) Own Interface 


2) Own Interface Impl 


Must it be present on the 


1) Yes 


1)No 


local disk when client 


2) Yes 


2) No 


program is compiling! 






Must it be present on the 


1)No 


1) Yes 


local disk when client 


2) No 


2) Yes 


program is running? 






Is it provided in the bootfile? 


1)No 


1) Yes 




2) No 


2) No 
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Example # 1 



--Heap .mesa 
DEFINITIONS 



--String .mesa 
DEFINITIONS 



Heap.bcd 
2/8/84 



String.bcd 
3/7/84 



Note: Since these are system 
interfaces, you usually only have 
the object code (beds), not the 
source code mesa). 



--DoSome .mesa 






DIRECTORY 


< 


String.bcd 
3/7/84 


String USING [...], 
Heap USING [...]; 






DoSome: PROGRAM 


< 


2/8/84 


IMPORTS String, Heap = { 






si: LONG STRING = "Hi!"; 
c: CARDINAL; 
c <- Stri ng . Lenqth[sl] ; 
Heap .AT 1 oc[ . . . ] ; 




• • « 

>• 





DoSome. bed 



Execute: DoSome. bed 



Loaded Implementations 




String.bcd 
J/7 '84 



Heap.bcd 
2/8/84 



The implementations for String.bcd and Heap.bcd 
are supplied at run time. 

(Note: Since these are system interfaces, the 
implementation is supplied in the bootfile.) 
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EXPORTS Clause 

The Exports clause lists the Interfaces for which this module supplies the 
implementation for some or all of the run-time items in that Interface. 

To EXPORT a procedure (or any other run-time item) to an interface, you 
need to do three things. 

• List the name of the interface in the DIRECTORY clause. 

• List the name of the interface in the EXPORTS list. 

• Include the word PUBLIC in the declaration of the procedure. 

Example: 

--IOImpI .mesa 
DIRECTORY 

10; 

IOImpl : PROGRAM EXPORTS 10 = { 

terminalState: {off, on, hung} «- off; 

ReadChar: PUBLIC PROCEDURE RETURNS[ i npu t : CHARACTER] = 
BEGIN 

END; 

ReadLine: PUBLIC PROCEDURE RETURNS[ i npu t : LONG STRING] = 
BEGIN 

* * * 

END; 
}... 
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Opaque Types 

It is also possible to export the implementation of a type. Opaque types 
provide a way to hide the internal structure of a type from the client. The 
implementation can then be changed as needed without affecting the 
clients of the Interface. 

In a DEFINITIONS module, you might have: 

--AnotherDef s .mesa 
AnotherDefs: DEFINITIONS = { 
SomeOpaqueType: TYPE; 

Ptr: TYPE = LONG POINTER TO SomeOpaqueType; 

- Or: 

AnotherOpaqueType:TYPE[<expression>] ; 

~ where < expression > is a positive integer specifying the word length 

The implementation in the PROGRAM module might look like: 

--AnotherDef slmpl .mesa 
DIRECTORY 
AnotherDefs ; 

AnotherDef slmpl : PROGRAM EXPORTS AnotherDefs = { 
SomeOpaqueType: PUBLIC TYPE = RECORD[v: ...]; 



When the word length is specified, a client using this type can declare 
variables of this type and perform the standard operations = , and #. 
Without a known length, no operations can be performed on the type so 
usually a LONG POINTER to the opaque type is included. 
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A Program Module Can Be Both Client and Implementor 

In this example, Typical Prog ram implements DumbDefs, and is a client of 
DumbDef s and String. 

Example: 

--DumbDef s .mesa 

DumbDefs: DEFINITIONS = { 

Language: TYPE = {english, french, german}; will use this 
SomeProc: PROC RETURNS[ i sit : BOOLEAN]; - will implement this 

--Typical Prog ram. mesa 
DIRECTORY 

DumbDefs USING TLanguaqel , 
String USING fEgui val entl ; 

Typical Prog ram: PROGRAM 

IMPORTS String EXPORTS DumbDefs = { 

Tang: DumbDefs . Languag e «- english; 
stringl: LONG STRING <- "Charlie Brown"; 
str1ng2: LONG STRING <- "Snoopy"; 

SomeProc: PUBLIC PROC RETURNS[isIt : BOOLEAN] = { 
IF (lang = english) AND 

( String. EguivalentT stringl. string2]) THEN RETURN[TRUE] 
ELSE. RETURN[FALSE]; 

• • • 

}• 
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Multi-Module Implementations 

The implementation of an interface is not necessarily a single module. 



--ManyProcs .mesa 

ManyProcs: DEFINITIONS = { 
*Procl: PROC [x,y: CARDINAL] ; 
/VProc2: PROC RETURNS [true : BOOLEAN] ; 
Proc3: PR0C[text: LONG STRING]; 




ManyProcs.bcd 



--ManyProcsAImpl .mesa 

DIRECTORY 
ManyProcs ; 

ManyProcsAImpl : PROGRAM 
EXPORTS ManyProcs = { 



Procl: PUBLIC PR0C[x,y: CARDINAL] 

> i ' 

}• 



■ { 



ManyProcsAlmpl.bcd 



--ManyProcsBImpI .mesa 




DIRECTORY 
ManyProcs ; 




ManyProcsBImpI : PROGRAM 
EXPORTS ManyProcs • { 




w Proc2: PUBLIC PROCEDURE 

Mr 


RETURNS[true: BOOLEAN] = { 


Proc3: PUBLIC PR0C[text: 

• • • 


LONG STRING] = { 


}• 





ManyProcsBImpI. bed 
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Configuration Files 

A configuration file groups together clients and implementations so that 
the implementation is loaded when the client calls it. 

Remember: 

If you import from System Interfaces - 
the implementation is in the bootfile. 

If you import from your own interface - 

the implementation should be supplied by your program. 

The easiest way to ensure that everything will be there when needed is with 
a configuration file. 

A configuration file is input to the Binder. The output of the Binder is a bed 
file (same as the output of the compiler). 
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Configuration File Syntax 

--Prog . conf ig 
Prog: CONFIGURATION 
IMPORTS String , Heap 
CONTROL ProgControl = { 

ProgControl ; 

Proglmpl ; 

The body (everything between BEGIN and END) should contain the names of 
all the PROGRAM modules that are part of your application. 

The CONTROL clause should list the PROGRAM module(s) that should be 
started when this configuration is started. Typically, only one program 
module will have mainline code; the other program module(s) will just 
contain procedures. 

The IMPORTS list should contain every DEFINITIONS module that must be 
imported from outside the configuration. That is, if any of the included 
PROGRAM modules need an implementation that is not supplied by any of 
the other PROGRAM modules, then the implementation must be IMPORTED 
from outside the configuration. More about this on upcoming slides. 



Modules: Definitions, Programs and Configurations 



Mesa Language Class -- March, 1988 



Example # 2 



--Heap .mesa 
DEFINITIONS 



--String . mesa 
DEFINITIONS 



--ProgDf .mesa 
DEFINITIONS 



Heap.bcd 
2/8/84 



String, bed 
3/7/84 



ProgDf. bed 
7/7/84 



--ProgControl .mesa 

DIRECTORY 

String USING [...], 
Heap USING [...], 
ProgDf USING [...]; 

ProgControl : PROGRAM 

IMPORTS String, Heap, ProgDf 

si: LONG STRING * "Hi!"; 
c: CARDINAL; 
c «- Stri ng . Length[sl] ; 
ProgDF.Proc[. . .]; 



= { 




String, bed 
3/7/84 



Hwp.bcd 

2/8/84 



ProgDF.txd 
7/7/84 



ProgControl.bcd 



--Proglmpl .mesa 

DIRECTORY 
ProgDf; 








1 ProgOF.bcd ■ 

| 7/7/84 ■ S*y 






Proglmpl; PROGRAM 
EXPORTS ProgDf = { 






Proc: PUBLIC PROC [. . .] • 

• • • 


■ { 











Proglmpl. bed 
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Example # 2 Continued 



--Prog . conf ig 

Prog: CONFIGURATION 
IMPORTS String, Heap 
CONTROL ProgControl 

BEGIN 

ProgControl ; 

Proglmpl ; 
END. 



Prog, bed 




String. bed 
3/7/84 



Heap.bcd 
2/8/84 



Bind: Prog.config 



Note: The implementation 
for ProgDF is supplied from 
within the config, so it 
doesn't need to be 
IMPORTED. 



Execute: Prog. bed 



Loaded Implementations 




String, bed 
3/7 84 



Heap.bcd 
28/84 



Implementations for String. bed and Heap.bcd 
are bound at run time when Prog is run. (The 
implementations come from the bootf ile.) 
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More on IMPORTING Into a Configuration 

An imports clause lists interfaces for which their implementations need to 
be supplied from elsewhere (outside the configuration). If one module in a 
configuration imports certain procedures from an interface, and another 
module in that configuration exports those procedures, the interface does 
not have to be imported into the configuration. 



TwoProgs: CONFIGURATION 
IMPORTS Heap, String 



CONTROL Prog2 
Progl ; 
Prog2 ; 



= { 



Note that ProgDefs does not need to 
be imported into the configuration, 
since Progl supplies the procedure 
that Prog2 requires. 



ProgDefs . Some P roc 
(Request is fulfilled) 



DIRECTORY 

Heap USING [Create], 
ProgDefs, 

String USING [CopyStri ng] ; 



Progl: PROGRAM 

IMPORTS Heap, Strin 
EXPORTS ProgDefs - 



SomeProc: PUBLIC PROC = { 
• • • j » 



}... 



DIRECTORY 
MoreDefs , 

ProgDefs USING [SomeProc]; 

Prog2: PROGRAM 

IMPORTS ProgDefs 
EXPORTS MoreDefs = { 

• • # 

ProgDefs . Some P roc [ ] ; 

>... 
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General Rule in Writing a Configuration 



Here are a few simple steps in writing a configuration file. Note that this is 
to be used a general rule of thumb. There are exceptions to this rule . Can 
anyone think of one? 

1) List in the body (between the BEGIN - END) all PROGRAM modules that 
make up the configuration. 

2) Decide which PROGRAM modules have mainline code that needs to be 
started when the configuration is loaded. List these PROGRAM modules 
in start order on the CONTROL line. 

3) Make a list of all of the IMPORTS of all of the PROGRAM modules listed in 
the body. Make another list of all of the EXPORTS of the PROGRAM 
modules listed in the body. Subtract the list of EXPORTS from the list of 
IMPORTS. Put the interfaces that remain in the IMPORTS clause of the 
configuration. 
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Inter-Modular Type Checking 

In a nutshell, the job of the binder is to match up export requests to import 
requests, and to ensure that type safety is maintained across module 
boundaries. Recall that when a module references interfaces, the compiler 
includes the time stamp of the interface as part of the .bed file. When the 
binder processes a config file, it reads the compiled versions of the 
constituent modules to verify that all modules reference the same versions 
of interfaces. 
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Exporting From a Configuration File 

An implementation for an interface may be given the same status as already 
loaded implementations (e.g. implementations in the bootf ile) by exporting 
the implementation from the configuration file. This is done by including 
the Interface in an EXPORTS clause in the configuration file: 

Example: 

--Exporter. config 

Exporter: CONFIGURATION 
IMPORTS String, Heap 
EXPORTS E*portedInterf ace 
CONTROL ExportControl = { 

ExportControl ; 

Exportlmpl ; 

Once Exporter is run, the implementation of Exportedlnterf ace remains 
loaded for use by later clients. The loaded state is preserved until the next 
system boot. 
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Naming Configuration Files 



The compiler and the binder both produce files with the .bed extension. 
Thus, the root name of your configuration file must be different from its 
component modules. 



WRONG WAY: 

The bound configuration overwrites the compiled source code. 



XYZ .mesa 




— ► 


compiler 




~ — ► 


XYZ. bed of Sept. 14,1985 2:17:42 




















XYZ. bed of Sept. 14,1985 2:20:11 


XYZ.'conf ig 






binder 







RIGHT WAY: 

The configuration file and its components have different 
names, so nothing is overwritten. 



XYZImpl .mesa 



— + 



compiler 



— + 



XYZImpl .bed 



XYZ.conf ig 



+ 



binder 



— ► 



XYZ. bed 
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Other Naming Conventions 

Configuration Modules: 

<Bar> . conf ig or <Foo>Too1 . conf ig 
i.e. Editor. conf ig, MathTool . conf ig 

Interfaces (Definitions Modules): 
Public Interfaces: 
<Foo> .mesa 

i.e. Edit. mesa, MT.mesa 
Private Interfaces: 

<Foo>Ops .mesa, <Foo>Def s .mesa 

i.e. Edi tOps .mesa, MTOps.mesa, MTDefs.mesa 

Implementation Modules (most frequently used): 
<Foo>Impl .mesa 

— or <FooXf unctionMmpl .mesa - recommended method 
-- or <Foo>AImp1 .mesa, <Foo>BImpl .mesa - old method 
i.e. Editlmpl.mesa, 

MTAImpI .mesa, MTBImpI .mesa 
MTFormlmpI .mesa, MTCaldmpl .mesa 

Client Modules (rarely used): 

<Foo>Contro1 .mesa or <Foo>Cl ient .mesa 
i.e. Edi tControl .mesa or MTC1 ient .mesa 
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More Examples 

This example shows how you might restrict a client to only see what is 
necessary in one interface. A separate interface that the client never sees is 
used by the implementation module(s). 



Client: PROGRAM 
IMPORTS FooDefs = 
BEGIN 

END. 



FooDefs: DEFINITIONS = 
BEGIN 

END. 




Foolmpl: PROGRAM FooPrivImpl: PROGRAM 

IMPORTS FooPrivDefs EXPORTS FooPrivDefs = 
EXPORTS FooDefs = BEGIN 
BEGIN 

END . 

END. 
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More Examples 



In this example, several program modules implement the private interface: 



FooDefs: DEFINITIONS = 
BEGIN 

END. 



Clientlmpl: PROGRAM 
IMPORTS FooDefs = 
BEGIN 

END . 




FooPrivDefs: DEFINITIONS 
BEGIN 

END. 



Foolmpl: PROGRAM 

IMPORTS FooPrivDefs 
EXPORTS FooDefs = 
BEGIN 

END. 



FooPrivAImpI : PROGRAM 
EXPORTS FooPrivDefs 
BEGIN 

• • • 

END. 



FooPrivBImpl : PROGRAM 
EXPORTS FooPrivDefs 
BEGIN 

END. 
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More Examples 

In this example, several program modules implement several private 
interfaces: 



Client: PROGRAM 




Foolmpl: PROGRAM 

IMPORTS FooPrivADefs, 

FooPri vBDefs , 

FooPri vCDefs 
EXPORTS FooDefs = 

BEGIN 

END. 


FooPrivAImpl 


FooPri vBImpl 


FooPri vCImpl 
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Configurations of Configurations 

In the earlier example, all of the implementation files can be combined into 
one configuration file: 

--FooDef slmpl .conf ig 
FooDefsImpl: CONFIGURATION 

IMPORTS Heap, String - or whatever - 
EXPORTS FooDefs = { 
Foolmpl ; 
FooPri vAImpl ; 
FooPrivBImpI ; 

}• 

Notice there is no CONTROL clause. The resulting file FooDef slmpl. bed can 
then be included in the client's own configuration: 

--C1 ient . conf ig 
Client: CONFIGURATION 

IMPORTS Heap, String - must include Clientlmpl & FooDefsImpl imports -- 
CONTROL Clientlmpl = { 
CI ientlmpl ; 
FooDefsImpl ; 

• • • 
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Dynamic Storage Allocation 
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Outline 

1. How is DSA in Mesa different? 

2. Heaps 

a. What are they? What kinds are there? 

b. How do you declare / get rid of them? 

c. How do you allocate / deallocate from them? 

d. What does a typical example of heap usage look like? 

e. How do you know which heap to use? 

3. Special data structures that use the Heap facility 

a. Strings 

b. Sequences 
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Overview of Dynamic Storage Allocation (DSA) 

When do you need DSA? When the amount of storage needed is not known 
until run-time. 

This lecture is intended to help you understand the different issues involved 
in dynamically allocating storage as it relates to the Mesa Language and to 
learn how to allocate storage efficiently. 

We will not be talking about low level issues such as operating system issues. 
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Why Dynamically Allocate? 

• Space, logical considerations 

Dynamic allocation is needed for objects which can not or should not be 
allocated in your program's global and local frames. 

Remember, storage for local frames comes from the Main Data Space. 
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How is DSA in Mesa Different? 



What's the big deal about DSA as it pertains to Mesa? How is it different 
from forms of DSA you've seen in other systems? 

• Choice of storage type 

• Type checking 

• No automatic garbage collection at either the micro or macro level 
Macro Level: 

myHeap ► _______ _____ 

Micro Level: 



MnkedListPtr 





NIL 



Dynamic Storage Allocation 



Mesa Language Class - May, 1988 



3-6 



Heaps 

• Heap facility = Heap Interface + NEW and FREE 

• Allocate fixed or arbitrary sized blocks of storage (nodes) 

• Three types of heaps: 

Normal: allows allocation of arbitrary-sized nodes 
Uniform: allows allocation of nodes less than or equal to a specified 
size 

MDS: allows allocation of arbitrary-sized nodes from the Main Data 
Space (MDS) 

• Public and Private Heaps 

Public: The environment provides a normal heap (the systemZone) 
and an MDS heap (the systemMDSZone). Information in 
these heaps can be shared among subsystems. There is no 
public uniform heap. 

Private: User can create private heaps (normal, uniform, or MDS) for 
specific purposes. 
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Choosing the Proper Heap Type for a Specific Application 

• If a set of programs requires a lot of private storage, it is often more 
efficient to create a private heap than to use the system-provided (public) 
heaps. 

• If objects being allocated are all the same size, uniform heaps are more 
efficient since less overhead is required for each node. 

• A process that uses a private heap instead of a system (public) heap avoids 
direct competition with other processes for resources. 

• System heaps can be used with low overhead for transient storage. 

• MDS heaps would generally be used by low-level system clients. 
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Using the Public Heaps 

In the Heap Interface, there are two constants that are available for use in 
your program. 

Heap.systemZone: READONLY UNCOUNTED ZONE; -the Normal system heap 
Heap. systemMDSZone: READONLY MDSZone; - the MDS system heap 

You can either reference these constants directly throughout your program, 
or create a local variable and assign the value of the system heap to it. 

Example: 

z: UNCOUNTED ZONE = Heap.systemZone; 
mz: MDSZone = Heap . systemMDSZone; 



Dynamic Storage Allocation 



Mesa Language Class - May, 1988 



3-9 



Using Private Heaps 

To create a private heap, you must call one of the Create procedures 
provided in the Heap interface. Abbreviated declarations are shown below 
with only the required parameters (others are defaulted). For a complete list 
of parameters, consult the Pilot Programmer's Manual. 

Heap. Create: PROCEDURE [Initial: Envi ronment. PageCount, 
maxSize: Envi ronment . PageCount «- Heap . unl imi tedSize , 

increment: Envi ronment. PageCount «- 4, ] 

RETURNS [UNCOUNTED ZONE]; 

Heap .CreateUnif orm: PROCEDURE [initial: Envi ronment. PageCount, 
maxSize: Envi ronment. PageCount «- Heap. unl imi tedSize , 
increment: Envi ronment. PageCount +■ 4, 

objectSize: Heap.NWords, ] 

RETURNS [UNCOUNTED ZONE]; 

Heap.CreateMDS: PROCEDURE [initial : Environment. PageCount, 
maxSize: Envi ronment. PageCount «- Heap . unl imi tedSize , 

increment: Envi ronment . PageCount «- 4, ] 

RETURNS [MDSZone]; 

Examples: 

z: UNCOUNTED ZONE <- Heap.Create[initia1 : 4]; 
uz: UNCOUNTED ZONE <- Heap .CreateUnif orm[ 

initial: 5, objectSize: 10]*, 
mz: MDSZone *■ Heap.CreateMDS[ initial : 2]; 



Hint: Since there are so many parameters to these procedures, it is 
recommended that you name all of the parameters that you are passing. 



Dynamic Storage Allocation 



Mesa Language Class - May, 1988 



3-10 



How to Get Rid of Private Heaps 

When you no longer need a private heap, you should delete it so that the 
space can be used by other processes. To delete private heaps, use one of the 
delete procedures provided in the Heap interface. Deleting a heap will 
automatically deallocate any currently allocated storage (which is what you 
usually want), unless the checkEmpty parameter is set to TRUE. 

Heap. Delete: PROC[ - for Normal or Uniform Heaps 

z: UNCOUNTED ZONE, checkEmpty: BOOLEAN <- FALSE]; 

Heap . Del eteMDS : PROC[ - forMDS heaps only 

z: MDSZone, checkEmpty: BOOLEAN <- FALSE]; 

Note: When you have deleted a heap, you should set your zone pointer to 
NIL to avoid accessing a previously deleted heap. 

Examples: 

z: UNCOUNTED ZONE - «- Heap . Create[4] ; 
mz: MDSZone <- Heap . C reateMDS[2] ; 

• • • 

Heap. Del ete[z]; 
z «- NIL; 

Heap . Del eteMDS[mz] ; 
mz <- NIL; 
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Allocating Storage From a Heap 

Nodes are allocated from a heap using the NEW operator. NEW returns a 
LONG POINTER to the object in the heap. 

Example: 

z: UNCOUNTED ZONE <- Heap.Create[initial : 5]; 

Node: TYPE = REC0RD[ .-..]; 

NodePtr: TYPE = LONG POINTER TO Node; 

currentNode: NodePtr <- z.NEW[Node] ; 
Graphically speaking: 



currentNode 

x 




Other Examples: 

sz: UNCOUNTED ZONE «- Heap . systemZone ; 

anotherNode: NodePtr <- sz . NEW[Node]; 

yetAnotherNode : NodePtr «- Heap . systemZone . NEW[Node] ; 
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Getting Initial Values 

There are several ways for a new node to pick up its initial values. They are 
called type initialization, field initialization, and explicit initialization. An 
example is the best way to understand the differences. 

Example: 

z: UNCOUNTED ZONE <- Heap . Create[ i n i ti al : 4]; 

NodePtr: TYPE = LONG POINTER TO Node; 

Node: TYPE = RECORD [ 

value: LONG CARDINAL <- 0, -this is a default for the field 

next: NodePtr <- nlllniit] «- [1, NIL] ; -this is a default for the type 

currentNode, otherNode: NodePtr; 
nillnit: NodePtr <- NIL; 

to explicitly set the values, use a record constructor 
currentNode <- z.NEW[Node <- [value: 4, next: otherNode]]; 

- if you omit a field in the record constructor, the field will pick up it 

- the default for the field. 

currentNode «- z.NEW[Node 4- [ , next : otherNode]] ; 

-- to pick up all of the field defaults, elide all fields 
currentNode <- z.NEW[Node <- [ , ]]; 

~ to pick up the default for the type, do not specify a record constructor 
~ if no type default exists, it will pick up the field defaults 
currentNode *■ z.NEW[Node]; 
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Getting Initial Values (Cont'd) 




Node 



value: 4 

next: otherNode 




Node 




value: 


0 


next: 


otherNode 




Node 




value: 




next: 


nillnit 




Node 




value: 


1 


next: 


NIL 
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Deallocating Storage From a Heap 

Nodes are deallocated from a Heap using the Mesa FREE operator. FREE sets 
the node pointer to NIL and then frees the storage used for the node. For 
FREE to make changes to the pointer, it must have a reference to the node 
pointer (since all parameter passing is call-by-value). 

Example: 

z: UNCOUNTED ZONE <- Hea|).Create[1nitial : 10]; 
NodePtr: TYPE = LONG POINTER TO Node; 
Node: TYPE » RECORD [ 

value: LONG CARDINAL <- 0, 

next: NodePtr *■ nillnit] «• [1, NIL]; 

currentNode: NodePtr <- z.NEW[Node «- [value: 4, next: NIL]; 

• • • - 

z. FREE[@currentNode]; 
Graphically speaking: 







currentNode •.. 












1 . State of heap before executing z.FREE[@currentNode]. 


currentNode <- NIL 


Node 




2. currentNode is set to NIL. 






z 

currentNode «- NIL 


: Node : 




3. Storage in the heap is freed. 
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Typical Use of a Heap in a Program 

DIRECTORY 

Heap USING [Create, Delete], 

• • • » 

Samp leProg ram: PROGRAM IMPORTS Heap, ... = { 

z: UNCOUNTED ZONE <- NIL; 

RecStructure: TYPE = REC0RD[ . . . ] ; 

PtrType: TYPE = LONG POINTER TO RecStructure; 

ptr: PtrType <- NIL; 

Allocate: PROCEDURE[ . . . ] = { 
ptr 4- z.NEW[RecStructure «- []]; 

...}; 

Deallocate: PROCEDURE[ . . . ] » { 
z. FREE[@ptr] ; 
. . . j , 

Cleanup: PROCEDURE = { 
If z # NIL THEN { 
Heap .Delete[z] ; 
z <- NIL }; 

• • • j * 

In1t: PROCEDURE = { 

IF z = NIL THEN z *■ Heap.Create[initial : 5] 

• • • y ; 

}. 
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Expanding a Heap 

When there is not enough contiguous space in the heap to allocate a node, 
the system automatically expands the heap by a specified number of pages. 
This number is specified by a parameter to the Create procedure, called 
Increment. (It is defaulted to 4.) Expansions are not guaranteed to be 
contiguous in VM. 

Let's trace a representation of an automatic expansion by the system when 
more space was needed in the heap. In this case: initial = 3, 
increment = 2 




1 . Heap is created in VM; 




2. Two different 1-page objects are allocated; 




3. First object is freed; program needs 2 pages for next object; 




v : -, ■■:■:•.:.■.„ 



4. Heap is expanded; 





5. New object is allocated from the extension; 



S:S:¥«?SKj<«¥S 
>;-:-!-;-:':-:-:'X-:<-: ; :-x-:-:'X':-:-x->: ; :-: 




6. A new 1-page object is allocated from previously used page that was freed. 
What would happen if objectSize > increment ? 
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Expanding a Heap (Cont'd) 

Fragmentation and other problems may be avoided by doing a manual 
expansion, if the heap needs to be expanded by more than increment 
number of pages. This expansion can be done by calling the Expand 
procedure in the Heap interface. 

Heap. Expand: PROC[ 

z: UNCOUNTED ZONE, pages: Envi ronment . PageCount] ; 
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Other Operations on Heaps 

• To determine initial parameters and current attributes of a heap: 

Heap.GetAttributes: PROC[z: UNCOUNTED ZONE] 
RETURNS[heapPages, maxSize, 

increment: Environment. PageCount, ... ]; 

• To return heap to its virgin state: 

Heap. Flush: PROC[z: UNCOUNTED ZONE]; 

• To release unused extensions of a heap: 

Heap. Prune: PROC[z: UNCOUNTED ZONE]; 

• To allocate an untyped node: 

Heap.MakeNode: PROC[ 

z: UNCOUNTED ZONE <- Heap . systemZone , n: Heap.NWords] 
RETURNS[p: LONG POINTER]; 

• To deallocate an untyped node: 

Heap . F reeNode : PROC[ 

z: UNCOUNTED ZONE <- Heap . systemZone , p: LONG POINTER]; 



Note: There are similar procedures for IN/IDS heaps. 
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Strings 

Definition from Day 1 : 

STRING: TYPE = POINTER TO StringBody; 

LONG STRING: TYPE = LONG POINTER TO StringBody; 

StringBody: TYPE = MACHINE DEPENDENT RECORD[ 

length: CARDINAL, 

maxlength: CARDINAL, -readonly 

text: PACKED ARRAY [0..0) OF CHARACTER]; 

Where: 

text is a PACKED ARRAY of characters 

maxlength is the maximum numbers of characters that text can hold 
1 ength is the number of characters currently in text 
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Allocating and Deallocating Strings 

1) Allocate fixed-sized storage from a local or global frame of the program: 

string: LONG STRING <- [256]; 

- sets maxlength to 256, length to zero & text is uninitialized 

2) Assign a string literal to a string variable: 

gString: LONG STRING "Hello"; 
lStrlng: LONG STRING <- "Hello"L; 

- sets maxlength to 5, length to5& text to the characters 'H, 'e, 7, 7, 'o 

3) Use the NEW operator to allocate storage from a heap: 

str: LONG STRING; 

str «- someZone. NEW[StringBody[8]]; - MUST specify size of String Body 

- sets maxlength to 8, length to zero & text is uninitialized 

Deallocate using Mesa construct FREE: 
someZone. FREE[9str]; 

4) Use procedures provided by the String interface to allocate storage from a 
heap: 

str: LONG STRING; 

str <- String .MakeStri ng[z: someZone, maxlength: 8]; 

- sets maxlength to B, length to zero & text is uninitialized 

Deallocate using String interface procedures: 
String , FreeString[z: someZone, s: str]; 
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Sequences 

Sequences are dynamic arrays 

• They must be declared within a record 

• There cannot be more than one sequence per record 

• They must be the last field in a record 

Syntax: 

ptr: LONG POINTER TO Rec; 
Rec: TYPE = RECORD [ 
<zero or more fields>, 

seq: SEQUENCE length: CARDINAL OF <el ementType>] ; 

/ \ t \ 

Reserved word 
indicating that a 
sequence is 
being declared 



length is a tag (of type 
CARDINAL) that indicates the 
number of elements in the 
sequence. It is non-assignable 
(e.g. length *- 3 is illegal). 




<elementType> is 
whatever the 
programmer needs 
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Sequence Example 

myRecordPtr: LONG POINTER TO MyRecord; 

MyRecord: TYPE * RECORD [ 

b oo 1 1 : BOOL, - These booleans are just for this example application 
b oo 1 2 : BOOL , — and are not specific to Sequences in general 
seq: SEQUENCE length: CARDINAL OF INTEGER]; 



To allocate this record to contain a sequence of ten elements and set the 
boolean variables: 

myRecordPtr «- someZone .NEW[ 

MyRec[10] «- [TRUE, FALSE, ]]; - MUST specify size of sequence 

Although other fields can be assigned during allocation, the sequence must 
be assigned in a separate statement, usually a loop. 

FOR i: CARDINAL in [0. .myRecordPtr. length) DO 
myRecordPtr. seq[1] <- 0; 
ENDLOOP; 

To deallocate this record: 

someZone . FREE[@myRecordPtr] ; 

To use the sequence: 

num: INTEGER; 

num «- myRecordPtr. seq[3]; 

num <- myRecordPtr[3]; -equivalent to above statement, and 

- num «- myRecPtr f .seq[3J; , and 

- num <— myRecPtr f [3]; 
ok: BOOLEAN <- myRecordPtr. bool 1; 

IF myRecordPtr. length > 5 THEN RETURN[TRUE] ; 
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Example Using Sequences, Strings and Heaps 

DIRECTORY 

Heap USING [Create, Delete]; 

Getlnfo: PROGRAM IMPORTS Heap = { 

Dossier: TYPE = REC0RD[ 

name: LONG STRING^ NIL, 

age: CARDINAL, 

ssn: LONG STRING <- NIL]; 
DossierPtr: TYPE = LONG POINTER TO Dossier; 

Personnel: TYPE = REC0RD[ 
currentEntry : CARDINAL <- 0, 

stuff: SEQUENCE maxEntries: CARDINAL OF DossierPtr]; 
Personnel Ptr: TYPE = LONG POINTER TO Personnel; 

people: PersonnelPtr «- NIL; 

z: UNCOUNTED ZONE <- Heap .Create[initial : 5]; 

~ Procedures 

Init: PROC = { 

people «■ Z.NEW[Personnel [6]] ; - allocate the sequence of pointers 
FOR i: CARDINAL IN [0 peopl e .maxEntries ) DO 

people[i] «- Z .NEW[Dossier] ; -allocate each of the records in the sequence 
people[i].age 0;~ initialize any fields that don't have defaults 
ENDLOOP; 
}; -of Init 
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Example Using Sequences, Strings and Heaps (cont'd) 

ExpandList: PROC 38 { -expands the sequence of pointers to include 3 new entries 
- create a new, larger (temporary) sequence 

temp: PersonnelPtr <- z . NEW[Personnel [peopl e .maxEntries + 3]]; 
FOR 1 :CARDINAL IN [0. .people. maxEntries) DO 

- copy each of the pointers to the Dossier records into the new sequence 

temp[i] <- people[1]; 

ENDLOOP; 

temp . currentEntry <- peopl e . currentEntry ; -copy over any other fields 
FOR jiCARDINAL IN [peopl e .maxEntries .. temp .maxEntries ) DO 

temp[j] «- Z. NEW [Dossier];- allocate the three new records in the sequence 

temp[j].age <- 0; 

ENDLOOP; 

Z.FREE[@people]; - deallocate the old sequence of pointers 

people «- temp; - make the global variable point to the new sequence; Why?? 

}; - of ExpandList 

ShrinkList: PROC [toBeDel eted : CARDINAL] = { 

- ShrinkList removes the record indexed by 'toBeDeleted' from the sequence of pointers 

IF toBeDeleted > s peopl e .maxEntries THEN RETURN - or handle elegantly 
ELSE { -move each of the pointers of the sequence over one position 

Z.FREE[Qpeople[toBeDeleted]]; ~ deallocate the record indexed by 'toBeDeleted' 
FOR i : CARDINAL IN [toBeDel eted .. peopl e .maxEntries - 1) DO 
people[i] <- people[i + 1];- copy each pointer over ignoring 'toBeDeleted' 
ENDLOOP; 

people[people. maxEntries] «- NIL; - reinitialize the last record in the sequence 
}; -End If 
}; -of ShrinkList 
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Example Using Sequences, Strings and Heaps (cont'd) 



people <- z .NEWrPersonnel r6~l"l; 



peopl e 



cu rrent Entry 
stuff: -^=ZZ 
maxEntries: 6 



0 1 2 3 4 5 



name: 
age: ... 
ssn: ... 




name: 
age: ... 
ssn: ... 



name: ... 




name: ... 


age: ... 




age: ... 


ssn: ... 




ssn: ... 



name: 
age: .. 
ssn: ... 



name: 
age: .. 
ssn: ... 



temp <■ z. NEWfPersonnel T 
people. maxEntries + 311 1: 

FOR i : CARDINAL IN rO-.xl DO 
tempfil ± PeopleMI; 



temp 




currentEntry:... 

stuff: — 

maxEntries: 9 
























0 


1 


2 


3 


4 


5 


6 


7 


8 



z. FREETQpeoplel : 
people ^ NIL 



people ± temp; 
people 
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Sequences vs. Array Descriptors 

• Array descriptors are useful for parameter passing. 

• Sequences are type-safe. 

• Sequences can be more readily treated as regular arrays. 

• Sequences must be allocated from a heap; arrays can be allocated from a 
local or global frame. 

• Sequences are the replacement for array descriptors. Newer code uses 
mostly sequences; older code uses array descriptors. 
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Fie view of DSA 

• Heaps are of the type you choose: normal, uniform, MDS, public, private. 

• To use a public heap, use a variable from the Heap interface 
(Heap.systemZone.) To use a private heap, call Heap. Create (and later 
Heap. Delete.) 

• To allocate and deallocate from heaps, use the language operators new 
and FREE. 

• Allocation is strongly typed; you almost never allocate untyped storage. 

• Allocate storage from a heap when it's not logical to allocate storage 
from a local or global frame. 

• Among the things allocated from a heap are strings and sequences, which 
require special attention. 

• Deallocation is your responsibility ; it's not performed automatically. 
When you create a heap, you must delete it. When you allocate storage 
for a data structure, you must deallocate that storage. 
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1. Tool Window code generated by FormSWLayoutTool (Handout) 

a. Global variables 

b. Main Program 

c. Call-back Procedures 

d. Command Procedures 

2. Adding code to your tool 
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FormSWLayoutTool Code 



The tool FormSWLayoutTool generates most of the tool code for you. You 
only have to supply the command procedures that are specific to your tool. 
See the Tool-Written Factorial Tool handout. 
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Global Variables 

--Types 

DataHandle: TYPE = LONG POINTER TO Data; 
Data: TYPE = MACHINE DEPENDENT RECORD [ 

msgSW(O): Window. Handle <- NIL, 

formSW(2): Window. Handle 4- NIL, 

fi1eSW(4): Wi ndow . Handle NIL, 

number(6): CARDINAL «■ 0, 

format(7): FormatType <- decimal]; 

FormatType: TYPE 3 {hex, octal, decimal}; 
-Variables 

data: DataHandle «- NIL; 

wh: Window. Handle <- NIL; — the window handle for the entire window 
zone: UNCOUNTED ZONE * Heap.Create[initial : 4]; 
busyBit: BOOLEAN «- FALSE; - is TRUE when tool is busy 

Where: 

datai-.msgSW, datat . f ormSW, 

data* . f i 1 eSW are window handles for the three subwindows 
data*, number holds the current value of Number in the tool window 
data* . format holds the current value of Format in the tool window 
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Main Program 

BEGIN 

~ Mainline code 
In1t[]; 
END. . . 



When the program is started, one call is made to the procedure In it. 
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Call-Back Procedures 

Init: PROCEDURE = { 

-This procedure is called once from the main program. 
-It creates the tool and registers a command with the Executive. 
Exec. AddCommand[ name: "FactorialTool . ""L, proc: NoOp, 

help: NIL, unload: Unload]; 
wh *- Tool .Create[makeSWsProc: MakeSWs, initialState: default, 
cl ientTransi tion : CI ientTransi tion , name: "FactorialTool "L, 
cmSectlon : "Factorial Tool "L] ; 

>: 

NoOp: Exec . ExecProc = { }; 

Unload: Exec . ExecProc = { 
IF Busy[] THEN { 

Exec .OutputProc[h]["Tool is busy. Sorry. \n"L]; 

RETURN[error] }; 
Tool . Dest roy[wh] ; 

Exec. RemoveCommand[h , "FactorialTool . ~"L] ; 
Done[] }; 

Cl ientTransi tion: Tool Window. Transi tionProcType = { 
-This procedure is called whenever the tool undergoes a user-invoked 
-transition between the 3 states: active, tiny, and inactive, 
-input Parameters: window, old, new 
SELECT TRUE FROM 
old = inactive a > 

IF data * NIL THEN data <- zone . NEW[Data <- []]; 
new = inactive => 

IF data # NIL THEN { 
zone.FREE[®data]}; 
ENDCASE; 

}; 
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Call-Back Procedures (cont'd) 

MakeSWs: Tool .MakeSWsProc = { 

-This procedure is called when the tool is created and whenever the tool's state 
-changes from inactive to active, or tiny. This procedure creates three subwindows. 
-input Parameters: window 
logName: LONG STRING <- [20]; 

Tool .UnusedLogName[unused : logName, root: "Factorial Tool . 1 og"L] 
data.msgSW <- Tool .MakeMsgSW[window: window]; 
data.formSW <- Tool .MakeFormSW[ 

window: window, formProc: MakeForm]; 
data.fileSW «■ Tool .MakeFileSW[window: window, name: logName]; 

}; 

MakeForm: FormSW.Cl ientltemsProcType = { 
-This procedure is called when the form subwindow is created. 
-Input Parameters: sw 
-Output Results: items, freeDesc 
format: ARRAY [0..3) OF FormSW. Enumerated <- [ 

["hex"L, 0], ["octal"L f 1], ["decimal "L , 2]]; 
items «- FormSW. Al 1 ocateItemDescriptor[3] ; 
items[0] «- FormSW. Numberltem[ 

tag: "Number"L, place: [6, FormSW. 1 i neO] , signed: FALSE, 
notNegative: TRUE, value: ©data. number] ; 
items[l] *■ FormSW. Enumeratedltem[ 

tag: "Format"L, place: [168, FormSW. 1 i neO] , feedback: all, 
choices: DESCRIPTOR[f ormat] , value: Qdata. format] ; 
items[2] FormSW. CommandItem[ 

tag: "Factorial "L, place: [6, FormSW. 1 i nel] , 
proc: Factorial]; 
RETURN[i terns : items, freeDesc: TRUE]; 

}; 
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Call-Back Procedures (cont'd) 

The Init procedure calls Exec.AddCommand passing in 2 procedures: NoOp and 
UnLoad. These procedures are then called as needed by XDE. Tool .Create is 
also passed 2 procedures: MakoSWs and CI ientTransltion. 

The procedure MakeSWs calls procedure Tool .MakeFormSW passing in the 
procedure MakeForm to make the form subwindow. MakeForm is then called as 
needed by XDE. 

These procedures that are passed to System procedures, and then called as 
needed by XDE are "Call-back procedures". 



FormSWLayoutTool Code 



Mesa Language Class - May, 1988 



3-37 



Scheduling Procedures 

Busy: ENTRY PROCEDURE RETURNS [isBusy: BOOLEAN] = { 
ENABLE UNWIND => NULL; 
isBusy busyBit; 
busyBit 4- TRUE; 

}; 

Done: ENTRY PROCEDURE = { 
ENABLE UNWIND => NULL; 
busyBit *■ FALSE; 

}: 
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Printing Procedures 

Write: Format . St ri ngProc = {Put.Text[data.f ileSW, s]}; 
Msg: Format. StringProc = {Put.Text[data.msgSW, s]}; 

Where: 

Format. StringProc = PROCEDURE[ 

s: LONG STRING, clientData: LONG POINTER <- NIL]; 
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The Put Interface 

While we're on the topic of displaying information to the screen, here is how 
to do it from any program. The Put Interface, defined in the Mesa 
Programmer's Manual, has many procedures to aid you in displaying data to 
windows. Some of the most commonly used procedures are shown here, but 
there are many others. Refer to the MPM. 

All of these procedures take a Window. Handle and (usually) a piece of data to 
be formatted. If the Window. Handle is NIL then the output is directed to the 
Herald Window. 

Put. Char: PROCEDURE[h : Wi ndow . Handl e <- NIL , char: CHARACTER]; 

Put. Text: PROCEDURE[h : Wi ndow . Handl e <- NIL , s: LONG STRING]; 

Put. Line: PROCEDURE[h: Wi ndow. Handl e «- NIL, s: LONG STRING]; 
- puts a LONG STRING and then a CR 

Put.CR: PROCEDURE[h: Window.Handle «- NIL]; 
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Dummy Command Procedures 

Factorial: FormSW. ProcType = { 

ENABLE ABORTED => {Done[]; CONTINUE}; 
IF Busy[] THEN { 

Msg["Too1 is busy.WL]; RETURN}; 
Process .Detach [FORK Factorial Internal [']]}; 

Factorial Internal : PROCEDURE = { 

ENABLE ABORTED »> {Done[]; CONTINUE}; 
Write[ w Factorial cal led\n w L] ; 
Done[] ; 

The resulting file from the FormSWLayoutTool can be compiled and 
executed. Command procedures like the above are used since the tool 
cannot know what the command is supposed to do. 

Whenever Factorial! (in the tool window) is invoked, the procedure 
Factorial is called. Factorial checks to see if the tool is busy. 

Factorial Internal is where the real work to calculate the factorial would 
be done. 
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Adding Code 

The dummy command procedures can be modified to contain either the 
actual implementation (shown below), or, more commonly, a call to an 
interface that implements the command (shown on next page). 

Factorial Internal : PROCEDURE = { 

ENABLE ABORTED => {Done[]; CONTINUE}; 
IF data, number > 12 THEN { -Out of range 
Put.CR[data.msgSW]; 

Put.Text[data.msgSW, "Too high, try again. "L] 
} 

ELSE { 

result: LONG CARDINAL l; 
temp: CARDINAL «- data. number; 
WHILE temp > 0 DO 

result <- result * temp; 

temp <- temp - 1; 

ENDLOOP; 
Put.CR[data.fileSW]; 

Put.Text[data.f ileSW, -The factorial of "]; 
Put . Decimal [data. f i 1 eSW , data . numbe r] ; 
Put.Text[data.f ileSW, " is "]; 
SELECT data. format FROM 

hex => Put.LongNumber[data.f ileSW, result, [16]]; 

octal => Put.LongNumber[data.f ileSW, result, [8]]; 

decimal «> Put. LongNumber[data. f ileSW, result, [10]]; 

ENDCASE ; 
Put . CR[data . f i 1 eSW] ; 

}; 

Done[] ; 

}; 



FormSWLayoutTool Code 



Mesa Language Class - May, 1988 



3-42 



Adding Code (con't) 

If the implementation of the command is something more complex than a 
simple procedure, it is wise to put the implementation in another module 
and simply make a procedure call to it. 

Factorial Internal : PROCEDURE = { 

ENABLE ABORTED »> {Done[]; CONTINUE}; 

MyDefs . Factorial [data. msgSW, data. f i 1 eSW, data. number] ; 
Done[] ; 

}; 
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Layout Mode / Edit Mode 



FormSWLayoutTool 




□ 




FormType: {033|, command, enum, longNum, numb, source, string, tag} 
Tag: Verbose Zone: 
AligiX Usebox Anyfont Root: SimpleTool 
Dolt! Clear! SetDefaults! Load! Save! Plagiarize! 




□ 

Verbose Ibis is a Phone Book Tool 

Find! Insert! Delete! 

Building: {fix the enums} 

Name: Phone= 

Address: 
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AlignX 



FormSWLayoutTool 



FormType: {QQSQ^ command, enum, longNum, numb, source, string, tag} 
Tag: Verbose Zone: 
AlignX Usebox Anyfont Root: SimpleTool 
Dolt! Clear! SetDefaults! Load! Save! Plagiarize! 



Verbose 

Find! Insert! Delete! 

Building: {fix the enums} 

Name: Phone 

Adoress: 



This is a Phone Book Tool 



FormSWLayoutTool 



FormType: {HJ|, command, enum, longNum, numb, source, string, tag} 
Tag: Zone: 
MfTr ro: Usebox Anyfont Root: SimpleTool 
Dolt! Clear! SetDefaults! Load! Save! Plagiarize! 



Verbose 

Find! Insert! Delete! 

Buildinq: {fix the enums} 
Name: 

Adoress: 



This is a Phone Book Tool 



Phone= 



Using the FormSWLayoutTool 



FormSWLayoutToal 



FormType: fWBI . command, enum, longNurn, numb, source, string, tag} 
Tag: Zone: 
AlignX 1155 ME Anyfont Boot: UseBoxTool 
Dolt! Qear! SetDefaults! Load! Save! Plagiarize! 



Name: 
Address: 



Find! 



Insert! 



Phone= 



Delete! 



UseBoxTool 



Name: 
Address: 



Find! 



Insert! 



Phone= 0 



Delete! 



-o 



a> 

CD 

o 

X 



I— 
to 
3 
(Q 

c 

Qi 
(Q 
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AnyFont 



FormSWLayoutTool 



-D 



FormTvpe: command, enum, longNum, numb, source, string, tag} 
Tag: Zone: 
Aligrtf Usebox Anyfont (toot: DefaultFontTool 

Dolt! a ear! SetDefaults! Load! Save! Plagiarize! 



■o 



Name: 
Address: 

Find! Insert! Delete! 



Phone= 



DefaultFontTool 



Name: 

Address: 

FindnserDelete! 



Phone = 0 



-a 



FormSWLayoutTool 



-O 



FormType: {[JHS]' command, enum, longNum, numb, source, string, tag} 
Tag: Zone: 
Ali<?iX Usebox WA'WiMt PSoot: AnyFontTool 
Dolt! Gear! SetDefaults! Load! Save! Plagiarize! 



Name: 
Address: 
[Find!.Jnsert!..M^! 



Phone= 



AnyFontTool 



Naime: 
Address: 

Find! Insert! Delete! 



Phone = 0 



-□ 
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Dolt! /Root: 



ForrnSWLavoutTool 



-□ 



FormType: {^JJ, command, enum, longNum, numb, source, string, tag} 
Tag: Zone: 
AligiX Usebox Anyfont Root: SimpleTool 
Dolt! Clear! SetDefaults! Load! Save! Plagiarize! 



Verbose 

Find! Insert! 

Name: 

Address: 



Delete! 



This is a Phone Book tool 
Phone= 

Building: {fix the enums} 



File: <CoP i 1 ot> WD>5 i mpl eTool . mesa 



Create OPos Edit Load Empty Save Time Store Reset Split Match 



All! S! RS! «: 



SR! R! «: 



— Si mpl eTool. mesa 

~ Create by FormSWLayoutTool on 31-JU1-87 16:02 
DIRECTORY 

Exec, 

Format, 

FormSW, 

Heap, 

Process, 

Put, 

TextSource, 
Tool, 

Tool Window, 
Window; 

SimpleTool: MONITOR 
IMPORTS 

Exec, FormSW, Heap, Process, Put, Tool = { 

DataHandle: TYPE = LONG POINTER TO Data; 
Data: TYPE = MACHINE DEPENDENT RECORD [ 

msgSW(O): Window.Handle * NIL, 

formSW<2): Window.Handle * NIL, 

fileSW<4): Window.Handle « NIL, 

verbose<6): BOOLEAN * FALSE, 
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Clear! 



FormSVVLayoutTool 








□ 

FormType: fBBBIL command, enum, longNum, numb, source, string, tag} 

Tag; Zone: 

AligiX Usebox Anyfont Itoot: SimpleTool 

Dolt! Q ear! SetDefaults! Load! Save! Plagiarize! 

, : □ 
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SetDefaults! 



FormoWLavautTool 



FormType: command, enum, longNum, numb, source, string, tag} 
Tag: Zone: 
AlignX Usebox Anyfbnt Root: SimpleTool 

Dolt! a ear! SetDefaults! Load! Save! Plapjiarize! 



Verbose 

Find! Insert! 

Name: 

Address: 



Delete! 



This is a Phone Book tool 
Phone= 

Buildinq: {fix the enums} 



Defaults 



[Defaults for new items] 
Readonly Invisible 

[Enumerated defaults] 

EE 553E5 : Feedback: {one} 



DrawBox 



HasContext 



[(Long) Number defaults] 

Radix: {decimal} NotNegative 

<Long)Default= 2147483647 



[String defaults] 



Feedback: {normal} 



Signed BoxWidth- 64 

<5hort)Defau1t= 32767 



BoxWidth= 0 



[MACHINE DEPENDENT RECORD] 
Starting word= 0 

[Global Things] 
EhumType: Form I terns 
ProcName: MakeForm 
StuffString: 



HandleName: data 
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Load! /Save! 



FormSWLavoutTool 



FormType: fl^HL command, enum, longNum, numb, source, string, tag} 
Tag: Zone: 
Alig/iX Usebox Anyfont Itoot: SimpleTool 
Dolt! Gear! SetDefaults! Load! Save! Plagiarize! 



Verbose 

Find! Insert! 

Name: 

AdoVess: 



Delete! 



Phone Book Tool 

Phone= 
Building: {fix the enums} 





File: <CoPilot>WD>5impleTool.t 


y 



Create OPos Edit Load Empty Save Time Store Reset Split Match Destroy 



All! S! RS! 



SR! R! *: 



Global [ 

enumType: Formltems, handleName: data, procName: MakeForm]; 
Booleanltemf 

tag: "Verbose", enumName: verbose, place: [6, 2], switch: verbose]; 
TagOnlyltem[ 

tag: "Phone Book Tool", enumName: phoneBookTool, place: [204, 2]]; 
Command I tern [ 

tag: "Find", enumName: find, place: [6, 19], pr oc: Find]; 
Command I tern [ 

tag: "Insert", enumName: insert, place: [54, 19], proc: Insert]; 
Command I tern [ 

tag: "Delete", enumName: delete, place: [114, 19], proc: Delete]; 
Stringltem[ 

tag: "Name", enumName: name, place: [6, 36], inHeap: TRUE, string: 
name]; 
Number I tern [ 

tag: "Phone", enumName: phone, place: [204, 36], signed: FALSE, 
value: phone]; 
Stringltem[ 

tag: "Address", enumiName: address, place: [6, 53], inHeap: TRUE, 
string: address]; 
Enumerated I tern [ 

tag: "Building", enumiName: building, place: [204, 53], choices: 
buildincj, value: building]; 

— Wa i tarn inn it [buddy, 43] "fix the enums" 
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Plagiarize! 



FormSWLayoutTool 




□ 




FormType: command, enum, longNum, numb, source, string, tag} 

Tag: Zone: 

AlignX Usebox Anyfont Root: SimpleTool 

Dolt! Clear! SetDefaults! Load! Save! Plaqiarize! 
— □ 




Expand! Compile! Bind! Run! Go! Options! 

Compile: 

Bind: 

Run: 

Log: {Compiler} 






[Command Central 12.3 of 17-May-85 12:40:38 




SimpleTool/be~ju lines: 154, code: 1406, links: 25, frame: 8, time: 56 

Elapsed time: 1:00 

. n 




Expand! Compile! Bind! Run! Go! Options! 

Compile: SimpleTool 

Bind: 

Run: 

Log: {Compiler} 




j n 

! Mesa Compiler 12.3 of 24-Sep-84 11:45:20 
31-Jul-87 16:22:59 

| Command: SimpleTool 
| SimpleTool. mesa 

| lines: 154, code: 1406, links: 25, frame: 8, time: 56 

I \ 
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Zone: 



FormSWLavoutTool 



FormType: command, enum, longNum, numb, source, string, tag} 

Tag: Zone: 
AligiX Usebox Anyfont Root: SimpleTool 
Dolt! aear! SetDefaults! Load! Save! Plagiarize! 



Phone Book Tool 
Phone* 



Verbose 

Find! Insert! Delete! 
Name: 
Address: 

Create OPos Edit Load Empty Save Time Store Reset 



File: <CoPil<bt>WD>SimpleTool.mesa 



-O 



All! S! RS! *: 



SR! R! 



data: DataHandle ♦* NIL; 

wh: Window. Handle * NIL; 

zone: UNCOUNTED ZONE * Heap.systemZone; 



FormSVVLayoutTool 



FormType: {jj[E5], command, enum, longNum, numb, source, string, tag} 
Tag: Zone: myHeap 

Ali^iX Usebox Anyfont Root: SimpleTool 2 
Dolt! aear! SetDefaults! Load! Save! Plagiarize! 



Verbose 

Find! Insert! 

Name: 

Adtfress: 



Delete! 



Phone Book Tool 
Phone 5 * 



File: <CoP i ot> WD>S i mpl eTool 2 . mesa 



j Create OPos Edit Load Empty Save Time Store Reset 



All! S! RS! «: 



SR! R! 



-□ 



data: DataHandle * NIL; 
wh: Window. Handle * NIL; 

myHeap: UNCOUNTED ZONE * Heap.Createfinitial: 4]j 
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Enum Props 



FormSWLayoutTool 



FormType: {QISSD' command, enum, longNum, numb, source, string, tag} 
Tag: Zone: 
AligiX Usebox Anyfont Root: SimpleTool 
Dolt! a ear! SetDefaults! Load! Save! Plagiarize! 



Verbose 

Find! Insert! 

Name: 

Address: 



Delete! 



Phone Book Tool 



Phone= 



Building: (fix the enums 



Enumerated Props » Tact: Buildinq « 



Close! Enum Name: building Tag: Building 

readonly invisible drawBox hasContext 
L^i! <'A»«'iltBS Feecback: {one} 

Value: building Proc: ChoiceName: building 



Choices: Wai tarn inn it [buddy, 43] "fix the enums" 



Change Choices field: 



Enumerated Props » Tag: Buildinq « 



Close! Enum Name: building Tag: Building 

readonly invisible drawBox hasContext 
ET2EZ2ES Feeotocfc: {one} 

Value: building Proc: ChoiceName: building 



Choices: one two three "more than one word" 
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FormSWLavoutTool 



FormType: {|20|, command, enum, longNum, numb, source, string, tag} 
Tag: Zone: 
Alip/iX Usebox Anyfont Root: SimpleTool 
Dolt! Clear! SetDefaults! Load! Save! Plagiarize! 



Verbose 

Find! Insert! 

Name: 

Address: 



Delete! 



Phone Book Tool 



Phone= 



Buildinq: {more than one word} 



Number Props » Taa: Phone « 



Gose! Ehum Name: phone Tag: Phone 

readonly invisible drawBox hasContext 

Signed NotNegative BoxWidth= 64 Default* 32767 Radix: {decimal} 
Proc: Value: phone 



String Props » Taq: Name « 



Gose! Ehum Name: name Tag: Name 

readonly invisible drawBox hasContext 

IN 1 '! AW Feedback: {normal} BoxWidth= 0 String: name 

FilterProc: MenuProc: 



Command Props » Taq: Find « 



Gose! Ehum Name: find Tag: Find 

readonly invisible drawBox hasContext 
Proc: Find 



Boolean Props » Taq: Verbose « 



Gose! Enum Name: verbose Tag: Verbose 

readonly invisible drawBox hasContext 
Proc: Switch: verbose 
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A 

Allocating 3-11,3-20 

Allocation 3-1,3-3,3-27 

C 

Call-Back 3-34-3-36 

Char 3-39 

CR 3-39,3-41 

Create 3-9-3-12, 3-14-3-16, 3-23, 3-27, 3-34, 3-36 

CreateMDS 3-9-3-10 

CreateUniform 3-9 

D 

Deallocating 3-14,3-20 

Deallocation 3-27 

Delete 3-10,3-15,3-23,3-27 

DeleteMDS 3-10 

Dummy 3-40 

E 

Expand 3-16,3-18 

Expanding 3-16-3-17 

F 

Flush 3-18 

FormSWLayoutTool 3-29-3-31,3-40,3-43 

FREE 3-6, 3-14-3-1 5, 3-20, 3-22, 3-24-3-25, 3-27, 3-34 

FreeNode 3-18 

FreeString . 3-20 

G 

GetAttributes 3-18 

H 

Heap 3-2,3-6-3-12,3-14-3-18,3-23,3-27,3-32 

L 

Line 3-39 
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MakeNode 3-18 

MakeString 3-20 

MDS 3-6-3-8,3-10,3-18,3-27 

N 

NEW 3-6, 3-11-3-12, 3-14-3-15, 3-20, 3-22-3-25, 3-27, 3-34 

Normal 3-6,3-8,3-10 

P 

Printing 3-38 

Private 3-6,3-9-3-10 

Prune 3-18 

Public 3-6,3-8 

Put 3-38-3-39,3-41 

S 

Scheduling 3-37 

SEQUENCE 3-21-3-23 

Sequences 3-2,3-21-3-26,3-28 

String 3-19-3-20,3-23,3-35,3-39 

Strings 3-2, 3-19-3-20, 3-23-3-25, 3-28 

systemMDSZone 3-6,3-8 

systemZone 3-6,3-8,3-11,3-18,3-27,3-32 

T 

Text 3-38-3-39,3-41 

U 

Uniform 3-6,3-10 
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Signals 



Signals 
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Outline 

1. Signals 

a. Signals overview 

b. Declaring signals 

c. Generating signals 

d. Catching signals 

e. The signal UNWIND 
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Layered Software 



Level 3 



Level 2 



Level 1 




Level 0 
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Types of Signals Crossing Abstraction Boundaries 



-- Informational signal (e.g. bounds fault) 
~ Caller error (e.g. bad data, wrong order) 

- Abstraction failure (e.g. buffer overflow, no channel) 

- Internal Error 



Signals 
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Signals vs. Polling 

An example of polling : 



~ -7 is a return code for in valid data. 
n <- Getlnput[]; 
WHILE n = -1 DO 

n <- Getlnput[]; - if input too big; try again 
ENDLOOP; 



An example of signals : 



n <- Getlnput[ ! InputTooBig => RETRY]; 
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The Signaller 

When a signal gets "raised", normal execution is suspended and control is 
transferred to the Signaller, which is part of Mesa's run-time support. It is 
the Signaller's responsibility to find and execute bodies of code that 
recognize the signal that was raised. The bodies of code that recognize the 
the signal are called catch phrases. 

Catch phrases are visited in reverse order of the standard scope rules; that is, 
inner blocks are visited first, then outer blocks. The order at the procedure 
level goes from the most recently called procedure to the least recently 
called procedure, beginning with the procedure that raised the signal. 

The path that the Signaller follows in order to find catch phrases that 
recognize a signal is called the propagation path. 
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3 Signal Operations 

- Declaring a signal 

~ Generating a signal (a.k.a. Raising a signal) 
Recognizing a signal 
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Declaring a Signal 

If you are going to use a particular signal only within one module, you 
should declare it only within that module. If you are going to use the signal 
across many modules, the signal must be declared in an Interface. (Unless 
otherwise specified, the term signal may stand for both SIGNAL and ERROR.) 

Syntax for Signals: 

<signalname>: SIGNAL[<arc|s if any>] RETURNS[<resul ts if any>]; 

Example: 

mySignal: SIGNAL[s: LONG STRING] RETURNS[ns: LONG STRING] ; 
Syntax for Errors: 

<errorname>: ERROR[<args if any>] RETURNS[<resu1 ts if any>]; 
Example: 

myError: ERROR[type: ErrorType]; 

Error-Type: TYPE = { . . . ,maxSizeExceeded , i nval i dParamete rs , 
inval idSize , insuf f icientSpace , otherError. . . , } ; 

** ERRORS cannot be RESUMEd. 



Signals 



Mesa Language Class - March, 1988 



4-9 



Initializing a signal 

In the implementation module, initialize the body of the signal to the 
keyword CODE: 

Example: 

mySignal: SIGNAL[s: LONG STRING] 
RETURNS[ns: LONG STRING] = CODE; 

The actual code for the signal will be dynamically bound at runtime. 



Signals 



Mesa Language Class - March, 1988 



4-10 



Generating a Signal 

If the signal doesn't return results : 

SIGNAL <s i gnal name>[<arguments if any>]; 

ERROR <errorname or s ignal name>[<arguments if any>]; 

RETURN WITH ERROR <errorname or signalname> 
[<arguments if any>]; 

ERROR; 

If the signal returns results : 

<leftside> <- SIGNAL <s ignal name>[<arguments , if any>]; 
<1eftside> «- ERROR <errorname or s ignal name>[<args , if any>]; 
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Generating a Signal 



Getlnput: PROCEDURE RETURNS[ i nputNumbe r : INTEGER] = { 



IF inputNumber NOT < 1000 THEN 
SIGNAL InputTooBig; 



Call Stack 

Main Prog 
Proc 1 
Proc2 
Proc 3' 



Getlnput 



InputTooBig 
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Recognizing Signals With Catch Phrases 

A propagating signal can be recognized by catch phrases. Catch phrases, in 
general, contain 2 parts: 

1) a recognition clause (specifying the signal of interest) and 

2) an action clause (specifying what should happen if that signal is 
recognized). Its syntax is similar to a SELECT statement. 

Catch phrases can be located in 2 places: 

1) during a procedure call (tucked in with the argument list) and 

2) at the beginning of any block (including loops). 
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Methods of Recognizing a Signal 
(in an Argument List) 

A catch phrase can be included in an argument list as the last item. That 
includes any procedure call, signal call, START, RESTART, STOP, JOIN, FORK, 
and WAIT. A ! (exclamation point) in the argument list marks the beginning 
of a catch phrase. 

Examples: 



n <- GetInput[!InputTooLittle => BEGIN ... END; 

InputTooBig => RESUME] ; -- example without parameters 

OpenChannel [size , handle ! InputTooBig , NoChannels => RETRY]; 
-- example with parameters 



Scope: If the signals InputTooLittle or InputTooBig are raised within 
Getlnput they will be recognized by the catch phrase attached to the 
Getlnput procedure call. 

Similarly, if the signals InputTooBig or NoChannels are raised within 
OpenChannel they will be recognized by the catch phrase attached to the 
OpenChannel procedure call. 
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More Examples of Recognizing a Signal 
(in an Argument List) 

Note that the catch phrases can be different each time that a procedure is 
called. 

Example: 

n <- Getlnput[ ! InputTooLi ttle => BEGIN ... END; 
InputTooBig => RESUME]; 

n <- Getlnput[ ! InputTooBig => RETRY]; 
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Another Method of Recognizing a Signal 
(With ENABLE Clauses) 

A catch phrase can be included at the beginning of any BEGIN - END block. 
This is done with an ENABLE Clause. 

Example: 

PlayAGame: PROCEDURE = { 



IF 





. . THEN 


BEGIN 




ENABLE OutOfMoney => { 






GetMoreMoney[] ; 






RESUME; 






}: 






<statement 1>; 




<statement 2>; 




END; 



<statement 3>; 



Scope: Signals raised in <statement 1> or <statement 2> will be recognozed 
with this catch phrase. Signals raised in <statement 3> will not be 
recognized. 
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More Examples with ENABLE Clauses 

An ENABLE Clause can also occur at the beginning of any DO loop. 
Example: 



TH ROUGH [1. .n] 



DO 






ENABLE { 






Sigl => LOOP; 






Sig2, Sig3 => RETRY; 

}; 




<statement 1>; 


<statement 2>; 


ENDLOOP; 



<statement 3>; 



Scope: Signals raised in <statement 1> or <statement 2> will be recognized 
with this catch phrase. Signals raised in <statement 3> will not be 
recognized. 
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The Scope of ENABLE 

BEGIN 

<ENABLE dause> 
<Decl arations> 
<Statements> 
<Exi tsCI ause> 
END; 

Catch phrases in an ENABLE clause cannot access variables declared in the 
enclosing BEGIN-END block. 

Example: 

BEGIN 

ENABLE OutOfMoney => { 

IF i < 0 THEN ... -- / is undefined at this point 

GetMoreMoney[] ; 

RESUME; 

} ; - of the Enable Clause 
i: CARDINAL «- 0; i is declared here 
i i + 1; 
END; 
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The Scope of ENABLE (con't) 

To get around this, use 2 sets of BEGIN and END: 

BEGIN 

<Dec1 arations> 
BEGIN 

<ENABLE dause> 

<Statements> 
END; 
<Exi tsCl ause> 
END; 

Example: 

BEGIN 

i : CARD I NAL <- 0 ; - declare i in an outer block 
BEGIN 

ENABLE OutOfMoney => { 

IF i < 0 THEN ... - valid to reference i here 

GetMoreMoney[ ] ; 

RESUME; 

}; 

i <- i + 1; 

• • • 

END; 
END; 
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Results of Entering a Catch Phrase 

A signal that has been recognized in a catch phrase can either be rejected 
(which means that the signal will continue to propagate up the call stack) or 
it can be caught which means that the signal will stop its propagation). 

A catch phrase can reject the signal three different ways: 

1) explicitly with a REJECT statement, 

2) implicitly by not being recognized, 

3) implicitly by falling off the end (not explicitly stopping propagation). 
Methods of "catching" a signal will be forthcoming. 
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Rejection Examples 

For the signal InputTooBig: 

1) InputTooBig is recognized but explicitly rejected: 

n «- Getlnput[ ! InputTooBig => { 
IF . . . THEN REJECT; 

...}]; 

2) InputTooBig is not recognized therefore, it is implicitly not caught: 
n <- GetInput[!InputTooLittle *> BEGIN END]; 

3) InputTooBig fell off the end because there was no explicit command 
about where control should go (just 'recognized', but not 'caught'): 

n «- Getlnput[ ! InputTooBig => { 

}]; 
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Catchy Statements 

RESUME 

CONTINUE 

RETRY 

LOOP 

EXIT 

GOTO 

If you want to "catch " a signal (stop its propagation), you must have one of 
these six statements at the end of a catch phrase. These statements tell the 
Signaller where to transfer program control. If none of these statements are 
used in a catch phrase, it is assumed that the Signaller is to remain in control 
and should continue along the propagation path looking for more catch 
phrases. 

Any signal that is not caught within the call stack will be caught by the 
debugger. The message that you will see is "Uncaught Signal 
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RESUME Statement 

Treat the signal call as a procedure call; return to the point the signal was 
raised . 

Example: 

BadData: SIGNAL[ . . . ] RETURNS[ . . . ] ; 
GetData: PROC[...] RETURNS[ . . . ] = { 
IF ... THEN 

n «- SIGNAL BadData[ . . . ] ; - control returns here after the RESUME 
... - with n getting assigned the returned value. 

y- 

- mainline code 

• • • 

n <- GetData[... IBadData => 

RESUME[ - with some number that will get assigned to n - ]] ; 

Control returns to where the signal was raised, but with a new value (if 
there is one). 

Note: There are two more-detailed examples of RESUME in later slides. 
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CONTINUE Statement 

Goes to the statement following the one to which the catch phrase belongs . 
• Catch phrase in an argument list: 

* • • 

temp MostRecentTemp[ INoTemp => CONTINUE]; 
<statement 1> 

Control passes to <statement 1>. 



• Catch phrase in an Enable Clause: 
... code fragment in a program 
IF ... THEN 



BEGIN 

ENABLE Nolnterest ==> CONTINUE; 
<statement 1>; 

n <- GetData[];« Noln terest may be raised here 

<statement 2>; 

END; 



< statement 3>; 



Control passes to <statement 3>. 
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CONTINUE Statement (con't) 



• Catch phrase in a Loop: 

... -- code fragment in a program 



WH 



LE ... DO 



ENABLE Nolnterest => CONTINUE; 
<statement 1>; 

n «- GetData[] ; Nolnterest may be raised here. 
<statement 2>: 



ENDLOOP; 
<statement 3>; 



Control passes to the next iteration. 
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RETRY Statement 

Go back to the beginning of the statement to which this catch phrase 
belongs. 

• Catch phrase in an argument list: 
... - code fragment in a program 
tries «- 0 ; 

n <- GetHandle[ INoneLef t => { 
tries +■ tries + 1; 

IF tries < 8 THEN RETRY ELSE GOTO errorMsg; }]; 
The call to GetHandl e is executed again. 



• Catch phrase in an Enable Clause: 
... -- code fragment in a program 
. THEN { 



IF 



ENABLE IncorrectResul ts => RETRY; 
<statement 1>; 

<statement 2>;~ IncorrectResults may be raised here. 
<statement 3>; 



^statement 4>; 



The block (starting with <statement l>) is started over. 
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RETRY Statement (con't) 

• Catch phrase in a Loop: 

... -- code fragment in a program 



WHILE ... DO 



ENABLE S1gl •> 


RETRY; 


<statement 1>; 




n <- GetData[]; 


-Sig 1 could be raised here 


<statement 2>; 





ENDLOOP; 



< statement 3>; 

The iteration in which the SIGNAL was raised (the current iteration) is 
started over (starting with <statement 1>). 
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LOOP, EXIT and GOTO (revisited) 

LOOP and EXIT are only meaningful within loops. 

• Example of LOOP: 

... - code fragment in a program 



WHILE ... DO 



ENABLE Sigl => 


LOOP ; 


<statement 1>; 




n «- GetData[] ; 


-- Sig 1 could be raised here 


<statement 2>; 





ENDL00P; 



<statement 3>; 
Control passes to the next iteration. 



• Example of EXIT: 

... — code fragment in a program 



WHILE ... DO 



ENABLE Sigl => 


EXIT; 


<statement 1>; 




n <- GetData[]; 


-- Sig 1 could be raised here 


<statement 2>; 





ENDLOOP; 



Cstatement 3>; 
Control passes to <statement 3>. 
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LOOP, EXIT and GOTO (con't) 



• Example of GOTO in a BEGIN - END block: 
... -- code fragment in a program 
IF . . THEN { 



ENABLE IncorrectResul ts => GOTO punt; 
<statement 1>; 

<statement 2>; -- IncorrectResults may be raised here. 



}: 

<statement 4>; 

EXITS 

punt => {...}; 



Control jumps to the EXITS clause looking for the arm labelled punt. 

• Example of GOTO in a Loop: 

... - code fragment in a program 
WHILE ... DO 



ENABLE Nolnterest => GOTO getOut; 
<statement 1>; 

n <- GetData[] ; -- Nolnterest may be raised here. 
<statement 2>: 



REPEAT 

getOut => NULL ; 
ENDLOOP; 
<statement 3>; 
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UNWIND 



Proc 


A 


Proc 


B 


Proc 


C 


P roc 


D 


Proc 


E 


Proc 


F 





t 



Signal 




1 



In the example above, assume procedure F raises a signal. Procedure A 
catches that signal and does a CONTINUE (which resumes control in the 
frame which the signal was caught), so procedures B, C, D # E, and F will be 
removed from the call-stack. 

A procedure that is going to be removed from the call-stack should be 
notified of that fact so that it may have a chance to clean up after itself (e.g. 
close files, deallocate storage, etc.). 

Mesa provides the signal UNWIND as a mechanism of notifying procedures 
that they will be removed from the call-stack. This allows a procedure to 
restore invariants if that procedure suddenly finds itself being removed as 
the result of a lower level signal being caught and handled by a catch phrase 
in a procedure higher in the call-stack. 
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The path of UNWIND 

When a catch phrase has recognized a signal, and is about to do a GOTO, 
EXIT, LOOP, RETRY, or CONTINUE, the UNWIND signal is raised at the point 
the original signal was raised. 

The propagation path for UNWIND is the same as that of the original signal. 
After UNWIND is passed to the last catch phrase in a given procedure frame, 
the frame is deallocated. When UNWIND reaches the "scoping boundary" 
of the catch frame that accepted the original signal, it stops and the jump 
corresponding to the statements above takes place, destroying the last 
catch frame in the process. (The UNWIND does not enter the catch phrase 
that accepted the original signal.) 

Since an UNWIND signal is just like any other signal, it may be recognized by 
procedures that wish to restore invariants before being removed from the 
call-stack. 

The propagation of UNWIND should never be stopped by one of the six 
magic "catchy" keywords. 

... -- Code fragment 
ENABLE UNWIND => 
BEGIN 

... dose files, etc ~ 

END; 
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Summary 

Declare the signal (or use a p re-declared signal) 
Generate I Raise the signal 

Recognize the signal (at which point you can perform some action or make 
some test) 

Catch or Reject the signal (IF the signal is caught with something other than 
RESUME, then the Signaller raises the signal UNWIND before transferring 
control.) 

If UNWIND was raised, it will follow the original propagation path. 

-** 

Transfer program control to the pre-specified place. 
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Full Signal Example 

InputTooBig: SIGNAL[numbe r : INTEGER] 
RETURNS[newNumber: INTEGER] = CODE; 

n: INTEGER; 

Getlnput: PROCEDURE RETURNS[ i nputNumbe r : INTEGER] = { 

inputNumber «- ... inputNumber gets some value -- 
IF inputNumber NOT < 1000 THEN 

inputNumber <- SIGNAL InputTooBig[inputNumber] ; 
... - do something interesting 

}; 



~ start of mainline code 

... - code fragment 

n <- Getlnput[ ! InputTooBig => 

IF number < 1100 THEN 
RESUME[999] 

ELSE { 

-- Message user about range of Input - 
RETRY }]; 
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Another Signal Example 

-- Just FYI (it is already declared in the String Interface) 
String . Stri ngBoundsFaul t : SIGNAL[s: STRING] 
RETURNS[ns: STRING] = CODE; 



... -- code fragment in a program 

str: LONG STRING «- GetSt r i ng F romSomehwhe re[ ] ; 
c: CHARACTER <- GetCharF romSomewhe reEl se[ ] ; 

String . AppendChar[st r , c ! String . Stri ngBoundsFaul t => 
BEGIN 

ns «- Stri ng . MakeStri ng[z , s.maxlength + 5]; -temporary 
Stri ng . Copy [from: s , to:ns]; - Copy old string to new string 
String . FreeString[z , s]; - Deallocate old string 
s t r «- n s ; — set global pointer to new string 

RESUME [ s t r ] ; - RESUME with the new string 

END]; 



After the BEGIN in the Catch Phrase 
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Before the END in the Catch Phrase 



s • 



ns S^*^ 



T 


h 


i 


s 




i 


s 




t 


h 


e 




s 


t 


r 


i 


n 













Signals 



Mesa Language Class - March, 1988 



4-34 



References 

J. J. Horning, Programming Languages, in T. Anderson and B. Randell 
(eds.) COMPUTING SYSTEMS RELIABILITY, Cambridge University 
Press, 1979. 

Roy Levin, Program Structures for Exceptional Condition Handling; Ph. D. 
thesis (available as technical report), Department of Computer Science, 
Carnegie-Mellon University, 1977. 

J. B. Goodenough, Exception handling: Issues and a proposed notation, 
COMM. ACM 18, no. 12, 1975. 

F. Christian, Exception Handling and Software Fault Tolerance, 10th 
Symposium on Fault Tolerant Computing Systems, Kyoto, 1980. 



Signals 



Mesa Language Class - May, 1988 



Mesa Streams 



Streams 



Mesa Language Class - May, 1988 



Outline 



1. Streams 

a. Streams overview 

b. Declaring Streams and initializing them 
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d. I/O Procedures 
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Mesa Streams 



Streams provide sequential access to data (a way to read or write a "stream" 
of bytes, words, etc.) [There are other facilities for handling random access of 
files by mapping segments of files to virtual memory. See the MSegment 
interface documented in the Mesa Programmer's Manual for more 
information.] 

Streams are device independent. (Floppy, tape drive, disk file, etc.) However, 
for the purposes of this lecture, a stream is a connection from a program to a 
file on the local disk in order to read and write that file. 
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Necessary Stream Operations 

~ Declare a stream variable 

Acquire the stream handle (initialize the connection) 
~ Use the stream (get data and put data) 

Delete the stream 
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Declaring Streams 

inStream: MStream. Hand! e ; 
inStream: Stream. Hand! e ; 

MSt ream. Handle and Stream. Hand 1 e are equivalent types. You can use them 
interchangeably. This is because: 

MStream. Handle: TYPE = Stream. Handl e ; 
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MStream and Stream 

MStream is a Tajo interface (documented in the Mesa Programmer's 
Manual.) 

Stream is a Pilot interface (documented in the Pilot Programmer's Manual.) 

To attach a stream to a local disk file, use the MStream interface. All device- 
specific information will be encapsulated in the stream handle. MStream is 
usually used in conjunction with the MFile interface, also documented in the 
Mesa Programmer's Manual. 

Once you have set up the stream, use the Stream interface to do your input 
and output. Once you have a connection, a stream to a disk file is just like a 
stream to any other device. 
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Acquiring Stream Handles 

Two step process: 

• Acquire a handle to the file (MFiie procedures) 

• Attach a stream to that file (MStream procedures) 

1) To acquire a handle to a specified file, use this MFile procedure 
(remember, this is just the definition!): 

MFile. Acquire: PROCEDURE [ 
name: LONG STRING , 
access: MFile. Access, 

- MFile.Access: TYPE = {readonly, writeOnly, readWrite, ...} 
release: MFile.ReleaseData, - explained later 
mightWrite: BOOLEAN <- FALSE , 

initial Length : MFi 1 e . Initial Length <- MFi 1 e . dontCare , 
type: MFile. Type <- unknown] 
RETURNS [MFile. Handle]; 

2) To attach a stream to that file, use this MStream procedure: 

MStream. Create: PROCEDURE [ 
file: MFile. Handle, 

release: MStream. ReleaseOata, - explained later 

options: Stream. InputOptions *■ St ream. defaul tlnputOpt ions , 

streamBase: Fi 1 e . PageNumber «- 0] 

RETURNS [stream: MStream. Handl e] ; 

Example: 

fileName: LONG STRING <- "junl^L; 

file: MFile. Handle <- MFi le. Acqui re[ 
name: fileName, access: readWrite, 
release: [NIL, NIL] IMFile. Error => GOTO exit]; 

stream: MStream. Handle «- MStream. Create[ 

file: file, release: [NIL, NIL] ! MStream . E rror => GOTO exit]; 
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Acquiring Stream Handles to Temp Files 

The MFile interface provides a mechanism of providing a temporary, 
anonymous file, if that is what your program needs. Once you have acquired 
a file handle to a temporary file, use the same MStream procedure shown 
earlier to attach a stream to it. 

MFile. AcquireTemp: PROCEDURE [ 

ty pe : MFile. Type , ~ MFile. Type: TYPE = {text, binary, directory, ...} 
initial Length : MFile. Initial Length <- MF i 1 e . dontCare , 
volume: Volume. ID <- [0, 0, 0, 0, 0]] 
RETURNS [MFile. Handle]; 

Example: 

tempFile: MFile. Handle «- MFile. Acqui reTemp[type: text 

IMFile. Error => GOTO exit]; 
tempStream: MStream. Handle «- MStream. Create[file: tempFile, 

release: [NIL, NIL] IMStream. Error => GOTO exit]; 
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ReleaseData 

The acquire procedures in both MStream and MFile have a parameter of type 
ReleaseData. (Definitions are below.) ReleaseData is used to specify how 
your program intends to share files with other programs. 

MFile. ReleaseData: TYPE = RECORD [ 
proc: MFi 1 e . PI easeRel easeProc <- NIL, 
cl ientlnstanceData: LONG POINTER <- NIL]; 

MStream. Rel easeData: TYPE = RECORD [ 
proc: MStream. PI easeRel easeProc «- NIL, 
cl ientlnstanceData: LONG POINTER <- NIL]; 

Unless you are planning to share the file with other processes, you should 
just pass the record [NIL, NIL ] for the ReleaseData parameter. 
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Accelerators 

When you know the name of the file that you want to attach a stream to, 
and you want to have one of the standard accesses, you can use 
an "accelerator" procedure to acquire the file handle and attach a stream to 
that file: 

MStream. Readonly: PROCEDURE[ 

name: LONG STRING, release: MStream . Rel easeData] 
RETURNS [MStream. Handle]; 

MStream.ReadWrite: PROCEDURE[ 

name: LONG STRING, release: MStream. Rel easeData, 
type: MFile.Type] 
RETURNS [MStream. Handle]; 

MStream. WriteOnly: PROCEDURE[ 

name: LONG STRING, release: MStream. Rel easeData, 
type: MFile.Type] 
RETURNS [MStream. Handle]; 

Example: 

fileName: LONG STRING <- "name"L; 

foo: MStream. Handle 4- MStream. ReadWrite[ 

name: fileName, release: [NIL, NIL], type: text 

IMStream. Error , MFile. Error => GOTO exit]; 
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Errors 

MStream and MFile procedures can potentially raise signals that you need to 
handle. These signals are: 

From the MFile Interface: 

MFile. Error: ERROR [file: MFi 1 e . Handl e , code: MFi 1 e . ErrorCode] ; 

MFile. ErrorCode: TYPE = MACHINE DEPENDENT {noSuchFile, 
conf 1 icti ngAccess , i nsuf f icientAccess , di rectoryFul 1 , 
di rectoryNotEmpty , illegalName, noSuchDi rectory , ...}; 



From the MStream Interface: 

MStream. Error: ERROR [ 

stream: Stream. Handl e , code: MStream. ErrorCode] ; 

MStream. ErrorCode: TYPE = MACHINE DEPENDENT {i nval i dHandl e , 
indexOutOf Range, inval idOperation , fileTooLong, 
f ileNotAvailable, invalidFile, othe r( LAST[CARDINAL] )}; 

Example: 

foo: MStream. Handl e «- MStream. ReadWri te[ 

name: "someName", release: [NIL, NIL], type: text 
IMFile. Error => { 
SELECT code FROM 
conf 1 ictingAccess , insuff icientAccess => GOTO AccessProbl ems ; 
illegalName =»> GOTO BadName; 
ENDCASE => GOTO All Other}; 
MStream. Error => GOTO StreamProblems] ; 
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Stream I/O 

Use the Stream Interface to perform any I/O with your stream. 

For getting information from the stream: 

Stream.GetByte: PROCEDURE[sH : Stream. Hand! e] 
RETURNS [byte: Stream . By te] ; 

Stream. GetChar: PROCEDURE[sH : St ream . Hand! e] 
RETURNS [char: CHARACTER]; 

Stream.GetWord: PROCEDURE [ sH : Stream. Hand 1 e] 
RETURNS [word: Stream. Word] ; »word=2bytes 



For sending information to the stream: 

Stream. PutByte: PROCEDURE[sH: Stream. Handl e , 
byte: Stream. Byte] ; 

Stream. PutChar: PROCEDURE[sH: Stream. Hand! e , 
char: CHARACTER]; 

Stream. PutWord: PROCEDURE[sH: Stream. Handl e , 
word: Stream. Word] ; - word = 2 bytes 

Stream. PutSt ring: PROCEDURE[sH : Stream. Hand! e , 

string: LONG STRING, endRecord: BOOLEAN <- FALSE]; 
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Reaching the End of the Stream 

All of the Stream. Get* I/O procedures will raise a signal if the end of the 
stream (end of file) is reached. You should catch this signal. 

Stream. EndOf Stream: SIGNAL[nextIndex : CARDINAL] ; 

Example: 

DO 

ch: CHARACTER; 

ch <- Stream. GetChar[ i nStream ! St ream. EndOf Stream => EXIT]; 

Stream. PutC ha r[outSt ream, ch] ; 

ENDLOOP; 
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Stream Blocks 



Stream Blocks provide a method of transfering arbitrary data structures. 
These structures are read into or out of a buffer of uninterpreted bytes. You 
can then LOOPHOLE the information into the structure of your choice. 

The Stream. Block is a record that contains a pointer to a buffer, the starting 
position within that buffer, and the stopping position. 



blockPointer 



startlndex 



stopIndexPlusOne 



Buffer of uninterpreted bytes 
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Stream Block Definitions 

Stream. Block: TYPE = Envi ronment. B1 ock; 

Envi ronment. Block: TYPE = REC0RD[ 

blockPointer: LONG POINTER TO PACKED ARRAY [0..0) 

OF Env1 ronment . Byte , 
startlndex, stopIndexPl usOne : CARDINAL]; 

Stream. Compl etionCode : TYPE = {normal, endRecord, 
sstChange, endOfStream, attention, timeout}; 

Stream. GetBl ock: PROCEDURE[sH : Stream. Handl e , block: Stream. Bl ock] 
RETURNS [bytesTransf erred : CARDINAL, why: Stream. Compl etionCode , 
sst: Stream. SubsequenceType] ; 

Stream. PutBl ock: PROCEDURE[sH: Stream. Handl e , 

block: Stream. Block, endRecord: BOOLEAN «- FALSE]; 
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Block Example 

Employeelnfo: TYPE = MACHINE DEPENDENT REC0RD[ 
name(O): PACKED ARRAY[0 . . 30 ) OF CHARACTER, 
ssn(15): LONG CARDINAL, 
employeeNumber(17) : LONG CARDINAL, 
gradeLeve1(19): CARDINAL]; 

RecordSize: CARDINAL = SIZE [Employeelnfo] * 2 ; -- SIZE returns # of words 
rec: LONG POINTER TO Employeelnfo; 

buffer: PACKED ARRAY[0 .. RecordSize ) OF Envi ronment . Byte ; 
block: Stream. Block «- [©buffer, 0, RecordSize]; 

inputStream: Stream. Hand! e «- MStream. ReadOnly[name : "input", 
release: [NIL, NIL] IMStream. Error, MFile. Error => GOTO exit]; 

outputStream: Stream. Handl a «- MStream. ReadWri te[name : "output", 
release: [NIL, NIL] IMStream. Error , MFile. Error => GOTO exit]; 

... ~ code fragment 

compl etionCode : Stream. Compl etionCode <- normal; 
UNTIL completionCode = endOfStream DO 

[bl ock . stopIndexPl usOne , completionCode, ] <- 
Stream.GetBl ock[ inputStream , bl ock] ; 

rec <- LOOPHOLE[block.blockPointer]; 

rec . gradeLevel rec . g radeLevel + 3; 

Stream. PutBl ock[outputSt ream, block, TRUE]; 

ENDL00P; 
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Block Example 



blockPointer 
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Get bytes from inputStream 
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After LOOPHOLE 
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gradeLeve! 
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buffer 



rec 



Put bytes to outputStream 
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Random Access 

Stream. Position: TYPE = LONG CARDINAL; -zero is the beginning of the file 

Stream. GetPosition: PROCEDURE [sH: St ream. Hand! e] 
RETURNS [position: Stream. Position] ; 

Stream. SetPosition: PROCEDURE [sH: Stream. Hand! e , 
position: Stream. Position]; 

Example: 

Advance: PROC[stream: St ream. Handl e , amount: Stream. Position] 
RETURNS[newPos : Stream. Position] = { 

position: Stream. Position «- Stream. GetPosition[sH: stream]; 
newPos «- position + amount; 

Stream. SetPosition[sH: stream, position: newPos]; 

}; 
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Deleting Streams 

Always delete the stream handle when you are through with it. This will 
release the file handle, so that other processes may use the file. Regardless of 
how the stream handle was acquired, use this procedure: 

Stream. Delete: PROCEDURE[sH : Stream. Handl e] ; 

Example: 

myStream: St ream . Hand! e <- MStream. ReadOnly[ . . . ] ; 
- Do I/O - 

Stream. Del ete[mySt ream]; 
myStream «- NIL; 
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Stream Example 

This example copies the contents of one file to another. 
... -- code fragment 

inStream, outStream: MSt ream. Hand! e ; 

inStream <- MStream. Read0n1y[ 

name: "1 etter . txf'L, release: [NIL, NIL] 
IMFile. Error, MStream . Error => GOTO exit]; 

outStream <- MStream. WriteOnly[ 

name: "1 etter. out"L, release: [NIL, NIL], type: text 
IMFile. Error, MStream . Error => GOTO exit]; 

DO 

Stream. Pu tCh a r [outStream, 

Stream. GetChar[inStream IStream. EndOf Stream => EXIT]]; 
ENDL00P; 

Stream. Del ete[ i nSt ream] ; 
Stream. Del ete[ outStream] ; 
inStream <- outStream «- NIL; 
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Processes and Concurrency 
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Outline 



1. Processes and Concurrency 

a. Concurrent execution 

b. New language features for processes 

c. Monitors 

d. Synchronization - Condition Variables 

e. More general forms of monitors 

f. Signals 
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Concurrency 



The Mesa architecture is designed for applications that expect a large 
amount of concurrent activity. Support for concurrent execution of multipSe 
processes is provided in the Mesa Language. Mesa's goal is to reduce the 
complexities associated with concurrent programming. 
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Concurrency 

In order to support the notion of dynamic processes, the Mesa Language 
must provide the ability to create new processes and also allow 
communication between the processes. 

There must also be a way to control the scheduling of these processes so 
that they are not manipulating shared data at the same time. 

To create new processes and synchronize their results, Mesa has provided to 
language operators: 
FORK/JOIN 

To control the scheduling of these processes, Mesa has provided the 
synchronization mechanism of: 
Monitors 
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Processes 



In Mesa, the creation of a new process is simply a special procedure 
activation that executes concurrently with its caller. 

Mesa allows any procedure (except an internal procedure - to be discussed 
shortly) to be invoked in this way, at the caller's discretion. 

It is possible to later retrieve the results returned by this procedure. 
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Call Stack 



Synchronous call Asynchronous call 

From A to B 



ProcZ 
Proc A 
Proc B 
ProcC 



ProcZ 



Proc A 



Proc B 



ProcC 
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New Language Operations and Data Types 

There are two new language operators and one new data type for 
supporting concurrent execution of multiple processes. 

PROCESS- the data type of the value returned by invoking FORK and used 
to identify the process in future operations, including JOIN. 

FORK - the operator that is used to create a new process. 

JOIN ~ the operator that is used to synchronize the return of a 
process. 
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The Process Interface 

Pilot also implements some routines that are used less frequently. These 
routines are defined in the Process interface (in the PPM). 

Process . Detach : PROCEDURE[PROCESS] ; 

the operator that is used to let a new process run by itself (that is, it will never 
beJOINed) 

Process. Abort: PROCEDURE[process : UNSPECIFIED] ; 

- notifies a specific process that it should abort 

Process . Pause : PROCEDURE[ ticks : Process .Ticks] ; 
puts a process to sleep for a specified amount of time 

Process. Yield: PROCEDURE; 

the calling process gives up control of the processor 

Process. SetTimeout: PROCEDURE[ 

condition: LONG POINTER TO CONDITION , ticks: Process .Ticks] ; 
sets the time limit a process will wait on a condition variable 



Process. Ticks is a tick of the process timer clock. There are procedures to 
convert from milliseconds < = > ticks and seconds < = > ticks. Consult the 
PPM. 
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Process Representation 

In the Mesa architecture, a process corresponds to either 

1) an instance of execution of a PROGRAM module or 

2) a procedure call that runs concurrently with its caller. 

Every process is represented as a Process State Block (PSB) residing on some 
operating system queue. A PSB contains information that allows the system 
to find the MDS in which the process is executing, its context (GF, LF # CB, and 
PC), its priority, and other information. 

Operating system queues are maintained in sorted order. 

Each non-running process will either be ready to run or blocked. 
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Process Representation (con't) 
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Example: Synchronous Call 

The unrelated computation will have to wait for the return of Read Line 
even though it does not need the results returned from that operation. 

Getlnput: PROCEDURE[buf f er: LONG POINTER TO Buffer] 
RETURNS[bytesRead: CARDINAL] = { 

• • • 

bytesRead <- ReadLi ne[buf f er] ; 

• • • 

<< unrelated computation >> 

• • • 

ReadLine: PROCEDURE[buf f ervar : LONG POINTER TO Buffer] 
RETURNS[numberOfBytes: CARDINAL] = { ...}; 
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Example: Asynchronous Call 

The new process is synchronized at termination. 

Getlnput: PROCEDURE[buf f er : LONG POINTER TO Buffer] 
RETURNS[bytesRead: CARDINAL] = { 
p: PROCESS RETURNS [CARDINAL]; 

* « • 

p <- FORK ReadLine[buffer]; 

<< concurrent computation >> 
bytesRead <- JOIN p; 
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PROGRAM Module Execution. 

Stack for Process N Stack for Process N + 1 



Getlnput 
p <- FORK ReadLine * 

JOIN p ** 

• • • 

NextProc 

• • * 

* The FORK creates a new PSB for ReadLine and places it on the ready 
queue. 

** When the JOIN is reached and ReadLine RETURNS, the results are retrieved 
and the call stack for Process N + 1 is deleted. 



ReadLine 



RETURN 



Processes and Concurrency 



Mesa Language Class - March, 1988 



5-14 



Example: Asynchronous Call 

If the new process is intended to function independently and the never be 
JOlNed then that process should be detached. 

Example: 

LookForMail : PROCEDURE [ma i 1 Box : MailBox] ■'{ 

• • « 

Process .Detach[FORK Real LookForMai 1 [mai 1 Box]] ; 

• • • 

}5 

Real LookForMai l is a procedure that has been declared elsewhere. The 
actual searching takes place in this procedure. 



Processes and Concurrency 



Mesa Language Class - March, 1988 



5-15 



Summary 

Mesa's goal is to reduce the complexities associated with concurrent 
programming by providing high-level language support. 

The method for passing parameters to a new process and retrieving its 
results is exactly the same as the corresponding method for procedures. 

No special declaration is needed for a procedure that is FORKed as a 
process. 

The cost of creating and destroying a process is moderate, and the cost in 
storage is only twice the minimum cost of a procedure instance. 

The cost of a context switch is roughly twice the cost of a procedure call. 

Therefore, ... 

You are encouraged to build systems that use many processes with a high 
rate of interaction. 
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Monitors -- Overview 

When several processes interact by sharing data, care must be taken to 
properly synchronize access to the data. 

The belief is that processes, in general, do not interact. When they do it is in 
small segments of code that manipulate shared data values. 

Safe communication implies only one process is operating in these critical 
sections at a time. 

Processes not only need to ensure mutual exclusion to data, but may also 
wish to enforce scheduling decisions. 

The idea behind monitors is that a proper vehicle for this interaction is one 
that unifies: 

1) the synchronization 

2) the shared data 

3) the body of code that performs the accesses 

4) the scheduling needs 
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Monitors ~ Overview 



For consistency, Mesa groups these components in a MONITOR module. 

Access to shared data is controlled by a MONITOR lock. One lock is 
associated with the monitor. When the monitor's code is entered the lock 
must be acquired. When a process leaves the monitor, the lock is released. 



Processes Enter 
Monitor 



Monitor 

(only one process is 
here at any time; 
others must wait) 



Processes Exit 
Monitor 



Access to the module are controlled by three types of procedures: 

external procedures ~ procedures that reside in a MONITOR module 

but execute outside of the monitor. 

ENTRY procedures - entry points into the monitor. 

INTERNAL procedures ~ shared monitor routines that are only called 

from other ENTRY or INTERNAL procedures 
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Monitoring Global Data 

Most common form of a monitor is to package all the data and procedures 
of the monitor within a single monitor instance. 

The monitor lock, in this case, is declared automatically in the global frame 
of the module. Thus, all of the global variables are monitored. 



Process B 
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Monitor Module Structure 

Monitor modules are declared much like program modules, except with the 
keyword MONITOR instead of PROGRAM. 

Example: 

DIRECTORY 

• • « t 

Samp leMoni tor: MONITOR IMPORTS ... EXPORTS . ..= { 

<<decl aration of shared variab1es>> 

<<code>> 
}• 

External procedures are declared as normal non-monitor procedures: 
P: <PUBLIC> PROCEDURE [ a rgs ] RETURNS[ results] = ... 

Every monitor has at least one entry procedure; these are declared as: 
Q: <PUBLIC> ENTRY PROCEDURE[args] RETURNS[ resul ts] = ... 

Internal procedures are declared as: 

R: INTERNAL PROCEDURE[args] RETURNS[ resul ts] = ... 

Note that external procedures should not reference global data as only 
monitored procedures should reference the global data (external 
procedures are logically outside the monitor). 
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Interfaces to Monitors 

In Mesa, the attributes ENTRY and INTERNAL are associated with a 
procedure's body, not with its type. Therefore, from the client side of an 
interface, a monitor appears to be a normal program module. 

For example, a monitor M with entry procedures P and Q might have an 
interface that appears as: 

MDefs: DEFINITIONS = { 

P: PROCEDURE[args] RETURNS[resul ts] ; 
Q: PROCEDURE[args] RETURNS[resul ts] ; 
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Mutual Exclusion 

Mutual exclusion in a monitor module is ensured by the monitor lock: 
The lock can only be held by one process at a time. 

The lock is implicitly acquired upon entry to an ENTRY procedure. 

The lock is implicitly released when the ENTRY procedure returns. 

Once the lock is held, other processes attempting to enter the monitor 
are blocked. 

Once the lock is released, one of the processes waiting for the lock or a 
new process that is attempting to enter the monitor can acquire the lock. 
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Mutual Exclusion Example 

Mutual exclusion to a structure that keeps count of the number of active 
and inactive objects in an environment: 

MutexDefs: DEFINITIONS = { 
CounterType: TYPE = RECORD[ 
active: INTEGER, 
inactive: INTEGER] ; 



Activate: PROCEDURE; 
Deactivate: PROCEDURE; 

Inspect: PROCEDURE RETURNS[counte r : Counte rtype] ; 
}• 
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Mutual Exclusion Example (con't) 

DIRECTORY 
MutexDefs; 

Mutex: MONITOR EXPORTS MutexDefs = { 

counter: MutexDef s . CounterType «- [0,0]; -this is the monitored data 

Activate: PUBLIC ENTRY PROCEDURE = { 
ENABLE UNWIND »> NULL; - explained later 
counter, active <- counter . active + 1; 
counter . i nactive <- counter, inactive - 1; 

}; 

Deactivate: PUBLIC ENTRY PROCEDURE = { 
ENABLE UNWIND => NULL; 
counter . active <- counter. active - 1; 
counter . i nactive *~ counter . inactive + 1; 

}; 

Inspect: PUBLIC ENTRY PROCEDURE 

RETURNS[counter: MutexDef s . Counte rType] = { 
ENABLE UNWIND => NULL; 
RETURN[counter] ; 

}; 
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Synchronization 

Synchronization among cooperating processes is expressed explicitly 
through operations on condition variables: 

Condition variables are declared as: 

c: CONDITION; 

Operations on condition variables: 

wait condition - puts process to sleep. The process that executes 

this statement exits the monitor and waits. 

NOTIFY condition ~ wakes up first process that is waiting 

BROADCAST condition wakes up all waiting processes 
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CONDITION Variables 



Condition variables are always associated with some boolean expression 
describing the desired state of the monitor data. This yields the general 
pattern: 

Example of a process (in the monitor) waiting for condition: 

... - code fragment 
WHILE -DesiredState DO 

WAIT c; -release lock 

ENDLOOP ; - reacquire lock 
<<execute with monitor lock held>> 

<<RETURM» release lock 



Example of a process (in the monitor) making condition true: 
... - code fragment 

<<make Desi redState TRUE>> - maybe as side effect of modifying global data 
NOTIFY c; 

<<continue execution>> 
«RETURM» -release lock 
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CONDITION Variables 



Processes Enter MONITOR 



i 



mm* 


Processes Temporarily 


WHILE ~Desi redState DO 


Exit MONITOR 










• • * 


Processes Re-enter MONITOR 


<<make Des i redState TRUE>> 




NOTIFY c; 

• • • 





c list 



Process A 



Process B 



Processes Exit MONITOR 



Process C 



Note that only one process can be in the MONITOR at a time. 
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NOTIFY Example 

DIRECTORY 
Al locDefs; 

StorageAllocator: MONITOR EXPORTS AllocDefs = { 
StorageAvailable: CONDITION; 

Block: TYPE = REC0RD[...]; -or some other data type 
ListPtr: TYPE = LONG POINTER TO ListElmt; 
ListElmt: TYPE = REC0RD[bl ock: Block, next: ListPtr]; 
freeList: ListPtr; 

Allocate: PUBLIC ENTRY PROCEDURE RETURNS[p: ListPtr] = { 
ENABLE UNWIND => NULL; - explained later 

WHILE freeList = N I L DO - boolean expression testing for desired sta te 

WAIT StorageAvailable; 

ENDLOOP; 
p «- freeList; 
freeList p. next; 

}; 

Free: PUBLIC ENTRY PROCEDURE[p: ListPtr] = { 
ENABLE UNWIND => NULL; 
p. next freeList; 

freeList <- p; ~ changes the desired state 
NOTIFY StorageAvailable; 

>! . 
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NOTIFY Example Graphics 



Processes Enter MONITOR 



Allocate: PUBLIC ENTRY PROCEDURE RETURNS[p: ListPtr] 
ENABLE UNWIND => NULL; 
WHILE freeList = NIL DO 

WAIT StorageAvai 1 abl e ; 

ENDLOOP; 
p <- freeList; 
freeList <- p. next; 



Free: PUBLIC ENTRY. PROCEDURE [p: ListPtr] 
ENABLE UNWIND => NULL; 
p. next <- freeList; freeList <- p; 
NOTIFY StorageAvai Table; 

}; 




Storage Available list 



Processes Exit MONITOR 



Process A 



Process B 



Process C 
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BROADCAST Example 

DIRECTORY 
Al locDef s; 

StorageAl locator: MONITOR EXPORTS AllocDefs = { 
StorageAvailable: CONDITION ; 

Block: TYPE = REC0RD[ . . . ] ; - or some other data type 
ListPtr: TYPE = LONG POINTER TO ListElmt; 
ListElmt: TYPE = REC0RD[bl ock: Block, next: ListPtr]; 
freeList: ListPtr; 

Allocate: PUBLIC ENTRY PROCEDURE [size: CARDINAL] 
RETURNS [p: ListPtr] = { 
ENABLE UNWIND => NULL; 

UNTIL << chunk of size words is available >> DO 
WAIT StorageAvailable; 
ENDLOOP; 

p <- << remove chunk of size words >>; 

}; 

Free: PUBLIC ENTRY PROCEDURE [p: ListPtr, size : CARDINAL] = { 
ENABLE UNWIND => NULL; 

e • * 

<< put back storage of size words >> 

• • • 

BROADCAST StorageAvailable; 

}; 

}• 
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Other Forms of Notification 

Since notification is a hint, a process can be awakened for reasons other 
than a notify or BROADCAST on a CONDITION. 

Timeouts ~ wakes up a process after a specified period of time. 

(The process must determine why it was awakened). 

Abort a process - wakes up a process and generates the error 

ABORTED. 
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Example: Timeouts 

DIRECTORY 

RemResDefs USING [Print]; 

RemoteResource: MONITOR IMPORTS RemResDefs EXPORTS RemResDefs = { 
ResourceAvail able: CONDITION; 
available: BOOLEAN «- TRUE; 

ConnectAndWork: PUBLIC ENTRY PROCEDURE[work : Work]= { 
ENABLE { 

ABORTED => GOTO return; -see next example 

UNWIND => NULL}; 
UNTIL available DO 

Process .Detach[FORK RemResDefs . Pri nt[<<note to user>>]]; 

WAIT ResourceAvail able; 

ENDLOOP; 
available «- FALSE; 
<<do work with connection>>; 
EXITS 

return => NULL; 

}: 

Disconnect: PUBLIC ENTRY PROCEDURE[ res : Resource]^ { 
ENABLE UNWIND => NULL; 

available «■ TRUE; 

NOTIFY ResourceAvail able; 

}! 

~ mainline code 

Process .SetTimeout[@ResourceAvai 1 able , RemResDefs . oneMin] ; 
Process . Enabl eAborts[@Resou rceAvai 1 abl e] ; 

}. 



Processes and Concurrency 



Mesa Language Class - March, 1988 



5-32 



Example: Abort 

DIRECTORY 
RemResDef s ; 

Somelmpl: PROGRAM IMPORTS RemResDef s ■ { 
p: PROCESS; 

MakeConnection : PROCEDURE[work: Work]= { 
p <- FORK RemResDef s . ConnectAndWork[work] ; 

}; 

Print: PUBLIC PROCEDURE[message : LONG STRING]= { 
<<print the message>> 

IF <<user does not want to continue>> THEN 
Process .Abo rt[p] ; - raises error ABORTED[p] 

}; 
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More General Forms of Monitors 

We've covered the basic form of a monitor, however, there are situations 
when one wants to provide a different form of monitoring. 

There may be times when the monitor code may be too large to fit inside 
one programming module, so it needs to be broken into several modules. 
This is called Multi-Module Monitors. The idea is that you have many 
programming modules but only one Logical Monitor and therefore, need 
only one Monitor lock. This requires an explicit declaration of the monitor 
lock. 

There also may be a need to not monitor the code but rather just the shared 
data structures. This is called Object Monitors and is implemented with 
monitored records. 
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Explicit Declaration of Monitor Locks 

To have the compiler use a programmer declared lock instead of inserting a 
anonymous global lock, you must include a LocksClause. The LocksClause 
goes just after the naming of a MONITOR module. 

General form of a LocksClause: 

LocksClause := empty | 

LOCKS Expression | 
LOCKS Expression USING 

identifier: TypeSpecif i cat ion 

A monitor lock must also be explicitly declared in the global frame of the 
Monitor: 

myLock: MONITORLOCK; 

And since the lock is going to be shared among several modules, it will need 
to be declared in a DEFINITIONS module, too. 

Example of the Monitor Module: 

SampleMonitor.mesa 
DIRECTORY 



SampleMonitor: MONITOR LOCKS myLock = { 
myLock: MONITORLOCK; 

• • • 

Procl: ENTRY PR0C[...] = {...}; 

• • • 
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Multi-Module Monitor Example 

~ Definitions Module 

MultiModulelnternalDefs: DEFINITIONS = { 
sharedLock: MONITORLOCK; 

P, Q, R f S: PROCEDURES . .]; 

<<other necessary def i ni tions>> 

— Monitor Module #1 
DIRECTORY 

Mul tiModul elnternal Def s ; 
MultiModulelmplA: MONITOR LOCKS sharedLock 
EXPORTS MultiModulelnternalDefs = { 

sharedLock: PUBLIC MONITORLOCK; 

P: PUBLIC ENTRY PROCEDURE[ . . . ] = .{...}; 
}• 

- Monitor Module #2 
DIRECTORY 

Mul tiModul elnternal Def s ; 
Mul tiModulelmplB: MONITOR LOCKS Mul tiModulelnternalDef s . sharedLock 
IMPORTS MultiModulelnternalDefs 
EXPORTS MultiModulelnternalDefs = { 

• « * 

Q: PUBLIC ENTRY PROCEDURE[ . . . ] = {...}; 

• • • 
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Multi-Module Monitor Example (con't) 

Monitor Module #3 
DIRECTORY 

Mul tiModul elnternal Def s ; 
Mul tiModulelmplC: MONITOR LOCKS Mul tiModuletnternalDef s . sharedLock 

IMPORTS MultiModulelnternalDefs 

EXPORTS MultiModulelnternalDefs = { 

• • • 

R: PUBLIC ENTRY PROCEDURE[ . . . ] = {...}; 

• • • 

- Monitor Module #4 
DIRECTORY 

MultiModulelnternalDefs; 
Mul tiModulelmplD: MONITOR LOCKS Mul tiModulelnternalDef s . sharedLock 

IMPORTS MultiModulelnternalDefs 

EXPORTS MultiModulelnternalDefs = { 

• • • 

S: PUBLIC ENTRY PROCEDURE[ . . . ] = {...}; 

• • • 
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Multi-Module Monitor Example (con't) 



M u 1 1 i M od u I e I nte m a I Def s 



MultiModulelnternalDefs: 
DEFINITIONS = £ 

sharedLock: monitoriock; 
P,Q,R,S: PROCEDURE^ . .]; 



}■ 




MultiModulelnternalDefs.sharedLock 
^ MultiModuleimplA 



DIRECTORY 

MultiModulelnternalDefs; 
MultiModuleimplA: monitor LOCKS 

sharedLock 
exports MultiModulelnternalDefs = { 

sharedLock: public monitorlock; 
...}. 



^ MultiModulelmplB 



DIRECTORY 

MultiModulelnternalDefs; 
MultiModulelmplB: MONITOR LOCKS 

MultiModulelnternalDefs.sharedLock 
iMPORTS.MultiModulelnternalDefs 



MuitiModuieimpIC 



DIRECTORY 

MultiModulelnternalDefs; 
MuitiModuieimpIC: MONITOR LOCKS 

MultiModulelnternalDefs.sharedLock 
imports MultiModulelnternalDefs 



\ 



MultiModuielmpID 



DIRECTORY 

MultiModulelnternalDefs; 
MultiModuielmpID: monitor LOCKS 

MultiModulelnternalDefs.sharedLock 
imports MultiModulelnternalDefs 



Note: All Modules use the same lock. 
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Monitored Records 

For situations in which the monitor data cannot simply be the global 
variables of the monitor module, a monitored record can be used. They are 
delcared as normal records with the key word MONITORED describing it: 

r: MONITORED REC0RD[x: INTEGER, ...]; 

Characteristics of Monitored Records: 

A Monitor Lock is automatically inserted in the record. 

Fields of the monitored record must not be accessed except from within a 
monitor which first acquires a lock. 

If a monitored record is passed as an argument to a procedure, it must 
only be done by reference. - 



Processes and Concurrency 



Mesa Language Class -- March, 1988 



5-42 



Object Monitor Example 

StackDefs: DEFINITIONS = { 

Handle: TYPE = LONG POINTER TO Object; 

Object: TYPE; - An Opaque Type! This will be a monitored record 

Pop: PROCEDURE [stack: Handle] RETURNS[ val ue : LONG CARDINAL]; 
Push: PROCEDURE [stack: Handle, value: LONG CARDINAL]; 
IsEmpty: PROCEDURE [stack: Handle] RETURNS[ 1 tls : BOOLEAN]; 
Create: PROCEDURE[size : LONG CARDINAL] RETURNS[stack: Handle]; 
Destroy: PROCEDURE [stack: Handle]; 

}. - End of StackDefs 



DIRECTORY 
Heap , 

StackDefs; 

Objectlmpl: MONITOR LOCKS stack USING stack: StackDefs . Handl e 
EXPORTS StackDefs = { 

myZone: UNCOUNTED ZONE <- Heap .Create[initia1 : 5]; 

Object: PUBLIC TYPE = MONITORED RECORD[ 
« some representation of a stack >> ]; 
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Object Monitor Example (con't) 

Pop: PUBLIC ENTRY PROCEDURE [stack: StackDefs .Handle] 
RETURNS[va1ue: LONG CARDINAL] = { 
ENABLE UNWIND => NULL; 

<< can access the record's fields in here >> }; 

Push: PUBLIC ENTRY PROCEDURE [stack: StackDefs . Handl e , 
value: LONG CARDINAL] = { 
ENABLE UNWIND => NULL; 

<< can access the record's fields in here >> }; 

IsEmpty: PUBLIC ENTRY PROCEDURE [stack: StackDefs . Handl e] 
RETURNS[ i tls : BOOLEAN] = { 
ENABLE UNWIND => NULL; 

<< can access the record's fields in here >> }; 

Create: PUBLIC PROCEDURE[size : LONG CARDINAL] 
RETURNS[stack: StackDefs .Handle] = { 
<< allocate the stack object and initialize here >> 
stack <- myZone.NEW[Object[]] ; 

}; 

Destroy: PUBLIC ENTRY PROCEDURE [stack: StackDefs .Handle] = { 
ENABLE UNWIND => NULL; 
<< free the stack object here>> 
myZone.FREE[@stack]; 

• • • 
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Object Monitor Example (con't) 



StackDefs 



Objectlmpl 



StackDefs: DEFINITIONS - { 
Handle: TYPE = ...; 
Object: TYPE; 
Pop: PROC ... 
Push: PROC ... 



}■ 



Client 



DIRECTORY 
StackDefs; 

Objectlmpl: MONITOR LOCKS stack 

USING stack.-StackDefs. Handle 
EXPORTS StackDefs = { 

Object: PUBLIC TYPE =■ 
MONITORED RECORD[ . . . ] ; 



DIRECTORY 

StackDefs; 
CI lent: PROGRAM 
IMPORTS StackDefs = { 




handlel: StackDefs. Handle *■ 


StackDefs .Create[sizel] ; 


handle2: StackDefs .Handle «- 


StackDefs .Create[size2] ; 


handle3: StackDefs .Handle «- 


StackDefs .Create[size3] ; 


StackDefs .Push[handle2, 15]; 




}• 






handle2 — — handles 
lock for stack 1 



lock for stack 3 



lock for stack 2 



handlel.monltorLock 



handle2 .monitor Lock 



15 



hand! 83 .monitorLock 



Logical Monitor 1 : 
Monitored Record 
of sizel 



Logical Monitor 2: 
Monitored Record 
of size2 



Logical Monitor 3: 
Monitored Record 
of size3 
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General Issues 
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Signals and Processes 

Each process has its own call stack. 

FORKing a process, therefore creates a new call stack. 

Recall that signals propagate up a call stack. 

This implies that signals cannot propagate across the gap created by FORKing 
a procedure. 

The only suitable targets for a FORK, therefore, are procedures that catch any 
signals they incur, and that never generate signals of their own that are 
expected to be handled by another process. 
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Signals and Monitors 

Signals within the body of an entry procedure require special attention: 
Monitor locks are not released when entry frames are unwound. 

Raising a signal from within an entry procedure does not release the 
monitor lock. 



Processes and Concurrency 



Mesa Language Class -- March, 1988 



548 



Releasing the Lock Using UNWIND 

To ensure the monitor lock is released when an entry procedure is being 
unwound, include an UNWIND catch in the outermost block of the 
procedure body. 

Example: 

Proc: ENTRY PROCEDURE[ . . . ] = { 

ENABLE UNWIND => { « restore invariant » }; 

• • • 

Or: 

Proc: ENTRY PROCEDURE[ . . . ] = { 

ENABLE UNWIND => NULL; Even if you don't need to do anything special, 
... - you must include this to release the lock 

}; 
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RETURN WITH ERROR 



When raising a signal from within an entry procedure you can use the 
RETURN WITH ERROR construct if you want to release the monitor lock. 

Failure: ERROR[kind: CARDINAL] = CODE; 

Proc: PUBLIC ENTRY PROCEDURE[ . . . ] RETURNS[cl, c2: CHAR] = { 
ENABLE UNWIND => NULL; 

• • • 

IF condl THEN ERROR Fai1ure[l]; 

IF cond2 THEN RETURN WITH ERROR Fa1lure[2]; 

• • • 
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Deadlocks 

Three common cases of pairwise deadlock: 

Two processes in a monitor WAITing, expecting the other to wake it up. 

Cyclic calls between two monitors. 

Embedded levels of monitors 
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Type Determination of Numeric Expressions 

Word Length Rules for Expressions (Balancing) 

In determining what type of operation (INTEGER, CARDINAL, LONG INTEGER, LONG CARDINAL, REAL) 
should be performed in an expression, a common word length must first be found. 

In general, the operation requiring the fewest automatic type conversions will be the one used. So, for 
numerics: 

1. If all (both) operands are short numerics, a short numeric operation will be used. 

2. If all (both) operands are long numerics, a long numeric operation wil be used. 

3. If one operand is a long numeric, the other operand will be lengthened and a long operation 
will be used. 

a. When an INTEGER is lengthened, its inherent type is LONG INTEGER. 

b. When a CARDINAL or NATURAL is lengthened, its inherent type is LONG INTEGER and 
LONG CARDINAL. 

4. If one operand is a REAL the other operand is converted and a REAL operation is used. 

Determination of Representation (Balancing) 

Once a common word length is found for an expression, the following rules will choose whether a 
signed (INTEGER, LONG INTEGER) or unsigned (CARDINAL, LONG CARDINAL) operation will take place. 

1. If the operands have exactly one common inherent representation, the operation defined for 
that representation is selected (and the target representation is ignored). 

2. If the operands have no common inherent representation but the target representation is well- 
defined, the operation yielding that representation is chosen. 

3. If the operands have both inherent representations in common, and if target representation is 
well-defined, it selects the operation. 

4. If the operands have both inherent representations in common but the target representation is 
ill-defined, the signed operation is chosen. 

5. Unary minus converts its argument to a signed representation if necessary and produces a 
signed result. 

If the operands have no representation in common and the target representation is ill-defined, the 
expression is in error. 
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About The Lab 

The Training Lab is located in room C401, next door. There are 20 machines available, so there should be 
one for everyone. The machines are already set up to contain all of the software you will need for the 
week. The XDE Mail Tutorials have also been installed in case you have not completed all of them or you 
would like to refer back to them. Here are a few other things to keep in mind: 

1) The afternoon labs are "Free Form". That is, you may come and go as you please, taking breaks and 
lunch as you wish. We do expect, however, that you do put some effort into working on the day's 
assignment. 

2) In order for the instructors to understand how well the information is getting through, we would like 
each of you to show one of the instructors a running version of your assignment. (We may choose to 
test a few key things to see how robust your implementation actually is.) 

3) There is an information card on each keyboard assigning you a logon name and password as well as 
other information about your machine. You do not need to be logged in to work in XDE, although you 
do need to be logged in to perform any operations over the net (e.g. Printing something). If you have 
your own logon name on the Xerox net, you may use it if you like. 

4) The lab machines have an established SearchPath of directories. These include a working directory 
(MesaWD), a Mesa Interface directory (MesaDefs), etc. To avoid problems, you should not alter this 
SearchPath. 

5) XDE Documentation is located in the back of the room. There are copies of the Mesa Language 
Manual, Mesa Programmer's Manual, Pilot Programmer's Manual, XDE User's Guide, and Hardcopy 
versions of the XDE Tutorials. You are encouraged to use these throughout the course, although they 
are to remain here for future students and classes. 

6) You may wish to personalize the User.cm on your workstation by changing the Hardcopy PrintedBy: 
option, or the default Brush, the Logon Name, etc. It is okay to do so, but you do not have to. 

7) At the end of each day, send a mail message to us mentioning what you liked or disliked about the 
day's work, any typos you noticed, bugs in the programs (ours not yours), or suggestions you may have. 
(We are constantly modifying the material based on students' suggestions.) The message may be as 
brief or lengthy as you like. We have found, though, that students who wait until Day 5 to summarize 
their thoughts in one message, tend to forget some of the thoughts that they had earlier in the week. 

8) Before you leave for an extended period of time (especially overnight), be sure to run some sort of 
DMT on the screen in order to protect them. There are many to choose from (e.g. DMT, BrushDMT, 
Poly, SpaceOut, Kinetic Fractal, etc.). 

9) Most Importantly: ASK QUESTIONS! We are here to help you. 

Our electronic addresses: MacKay:OSBU North:Xerox, HerzrOSBU North:Xerox 
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Compiler Exercise 

There are two parts to this assignment to help you learn mesa syntax. In Part I you will fix errors in code 
already written for you. In Part II you will write some code yourself. 

Part I: Syntax Errors 

The file CompilerPractice.mesa has several intentional compiler errors. Use Command Central (or the 
executive) to compile CompilerPractice.mesa. You can see the results in the Compiler log,which is 
displayed in the bottom subwindow of Command Central. (If you used the executive to compile, then 
you will have to load the file Compller.log into a file window.) 

When the compiler finds an error, it gives an indication of the error (an error message), the position of 
the error in the source file, a listing of the offending line, and the fix the Compiler assumed in order to 
continue (when possible). 

The compiler will not go on to the next pass after it detects an error. This means that you must fix the 
errors and compile the program again. If it finds more errors, then you must fix them and repeat the 
cycle. 

Upon successfully compiling the program, run the program in the Executive by typing 
'CompilerPractice'. 

Part II: Simple Programming 

If you ran CompilerPractice, you will have noticed that the tool is a simple Math tool. You might have 
noticed that there are five functions (add, subtract, multiply, divide, yx). The first four functions have 
already been implemented. You will implement the function yx. 

In the program, each function is implemented in separate procedures. The procedure YtotheXInternal, 
which is where the work should be done, has already been started for you. The code for printing the 
answer has been provided. You need to calculate what Y to the X power is and store the answer in the 
variable answer. The values of x and y are stored in data.x and data.y, respectively. (Don't worry about 
all cases; you need only be concerned with relatively small numbers for x and y. This is just to give you 
some experience in writing very simple mesa code.) 

To test your program, you need to unload the previous version by typing 'Unload CompilerPractice' in 
the executive. Then, recompile and then run your new version (like you did in Part I). 
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Debugger Examples 
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Learning Some Debugger Commands with MiscProcs 



These examples are to give you a little experience with debugger before working on today's debugger 
assignments. 

This is the same MiscProcs example that is used in the on-line debugger tutorial. If you are not completely 
comfortable with the concepts covered in the on-line tutorial, or if you haven't done the debugger 
tutorial, you should go through this example. Otherwise, feel free to go on to the next example. 

The purpose of this example is to introduce you to some of the more useful aspects of the debugger's 
interpreter. At this point, you should make sure that you have the file MiscProcs.mesa on your Copilot 
volume. Load the file into an empty window. Compile the module either from the Executive (by 
typing 'Compiler MiscProcs') or by using the Command Central tool. If it does not compile successfully, stop 
and ask a lab assistant for help. Otherwise, run the program by typing 'MiscProcs/d' in the Executive. 

This command loads the file MiscProcs.bcd, but does not start it. What this means is that the global frame 
has been allocated for the program (and certain information has been recorded in the operating system) 
but none of the mainline code has been executed and none of the variables have been initialized.The 
switch /d, calls the debugger. If there is not a sword window to debug locally (or if it is tiny), then one will 
be made activefor you; otherwise, search the active windows looking for the local debugging window. At 
this point, you can refer to the module from the debugger (since its global frame has been allocated). 

In this example, you should type whatever is underlined into the debugger file subwindow. Let's begin 
with: 

1. >SEt Module context: MiscProcs - type a carriage return (CR) at the end of the line 

2. > A:J - type a space, then the characters "A;j" followed by a CR 

3. > Factor 1 air 51 - type a space at the beginning of lines 3 thru 9 

4. > 170B7 

5. >_Aij 

6. > Am 4- 30; Am t 70 

7. > _A 

8. > InterChanger3.71 

9. >_A 

On line 1, you told the debugger the module that you were interested in. 

On line 2, you used the interpeter to examine the variables "A" (an array) and "]" (a long cardinal). (The 
Interpreter is invoked by typing a space at the beginning of a line.) Their values look unfamiliar; they 
weren't initialized because the module hadn't been started (which explains the warning that you got in 
the debugger: "{global frame number} is not started"). 

On line 3, you made an interpreted call to the procedure Factorial in module MiscProcs. You passed the 
necessary parameter (in this case, a cardinal), and it returned to you an answer (the factorial of your 
number). This number may have been in an octal format (denoted by the "B" after the number). (Note 
again that you were warned, before the procedure call, that the module had not been started). 

On line 4, you interpreted the number "170B" by typing a "?" after the number. The reason that you did 
this was because the answer returned by procedure Factorial was probably in octal format, and you 
wanted to see what the answer was in decimal format. What you got when you interpreted "170B" was its 
value in octal, hexidecimal, decimal, ascii, and other formats. You can also change the default format by 
invoking Options! in the Sword FormSW and changing the value of the enumerated type for cardinals. 
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On line 5, you re-examined the variables "A" and "j" and found that they contained values that were 
assigned to them in the program ("A" initialized to all zeroes and "j" being set by the Factorial call to 120). 
How did the variables become set? You executed code in the module when you called the procedure 
Factorial. This caused all the global variables in the module to be initialized. 

On line 6, you stuffed your own values into the 3rd and 7th spots in the array "A." 

On line 7, you examined "A" to make sure that the array contained your values. 

On line 8, you made an interpeted call to the procedure Interchange, which interchanges the two values in 
the spots in the array that you specified (in this case, the third and seventh spot). 

On line 9, you re-examined "A" to check that the values for the 3rd and 7th spot had been interchanged. 

Your debugger should look similar to the following: 



go: {proceed, abort, kill, screen, start} Client: {local} destroy! 

read: { } write : { } processes configs attach: {source, symbols} 

source! findModulel rep?! showType! type&bltsl options! 

break: {set, clear, clearall, list, attachCond, attachKey} watch: {off} 
; q 

You called? 

>SEt Module context: MiscProcs 

> A; j 

112560B is not started! 

A » (13)[1, 2, 6400B, 17B, 20B, 20156B, 67564B, 20146B, 67565B, 67144B, 20141B, 
67144B, 20000B] 
112560B is not started! 
j = 4640650441B 

> Factorial[5] 
112560B is not started! 
170B 

> 170B? 

170B = 78X = 120 = 'x = 7:8 

> A; j 

A » (13)[0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0] 
j ^170B 

> A[3] *■ 30; A[7] «- 70 

> A 

A =■ (13)[0, 0,0, 30, 0,0, 0,70, 0,0, 0,0,0] 

> Interchange [3, 7] 

> A 

A * (13)[0, 0,0, 70, 0,0, 0,30, 0,0, 0,0,0] 
> 
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Now, try the following in the debugger: 

10. > MakeLinkedUstRI 

11. > headNode 

12. > headNodet 

13. > headNode. nextt 

14. > headNode. next. nextt 

15. > headNode. next. next. nextt 

On line 10, you made a call to the procedure MakeLinkedList, which creates a singly-linked list where the 
size is specified by the caller (in this case, the size is 4). The global variable headNode is a pointer variable 
that acts as the header for this linked list. 

On line 11, you examined the value of headNode and found the address of the record that it points to. You 
know that it's an address by the up-arrow that follows the returned number. 

On line 12, you asked to dereference the pointer headNode and examined the contents of what headNodo 
points to. Notice the field next and the fact that it contains a number with an up-arrow after it. This field 
points to the next element in the linked list. (The other field in this record, str, is a LONG STRING of 
length = 1 and maxlength = 1 [hence the "(1,1)"] that contains the text "D".) 

Online 13, you asked to examine the contents of what the next field points to. Notice that you did not have 
to type headNodet. nextt, only headNode . nextt, due to the auto-dereferencing feature that exists in the Mesa 
language and is included in the interpreter. 

On line 14, you examined the contents of what the next next field points to. 

On line 15, you looked at the final element in the linked list. Notice that the next field for this last element 

is NIL. 

The last part of your debugger should look similar to the following. 



go: {proceed, abort, kill, screen, start} Client: {local} destroy! 
read: { } write : { } processes configs attach: {source, symbols} 
source! flndModule! rep?l showType! type&blts! options! 
break: {set, clear, clearall, list, attachCond, attachKey} watch: {off} 

□ 

> MakeLinkedL1st[4] 

X headNode 
headNode = 4021731Bt 

> headNodet 

headNode =» [str:4021736Bt( 1, 1)"D\ next : 4021742Bt] 

> headNode. nextt 

next = £str:4021747Bt(l,l)"C", next:4G21753Bt] 

> headNode. next. nextt 

next = [str:4021760Bt(l,l)"B'\ next:4021764Bt] 

> headNode. next. next. nextt 

next » [str:4021771Bt(l,l)"A\ next:NIL] 
> 
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Second Example: "Function 



n 



This example takes you through a fairly realistic debugging session. Suppose that you have just written a 
program called Function.mesa and you want to test it to see if it gives the correct answers, and if it catches 
human errors in input and handles them in a desirable way. Load Function.mesa in a window, then 
compile (your favorite way) and run it from the executive (this time, with no switches.) Also, in the 
executive type 'help function' to see how to use the program. Test the program by entering the following 
commands in the Executive: 

function s/20 
function c/5 
function s/6 s/10 c/4 
function q/ 

At this point, the program fails and the debugger gets called. (If a debugger window is not automatically 
brought up, search the active windows looking for the local debugging window.) In the debugger, you're 
told that an uncaught SIGNAL caused the debugger to be invoked. SIGNALS have names, and if this signal 
can't be identified, it is because the symbols for the module that raised the signal are not present on your 
disk. In this case, the module that contains the signal is StringslmplB. You may not have the symbols for the 
module StringslmplB, and you, therefore, don't have any information other than the fact that the 
program Function. bed had made a call into StringslmplB. If you don't already have the file 
StringslmplB. bed on your local disk, ask a lab assistant to give you the file. After you have loaded the file 
onto your machine, type the letters "rd" in the debugger: 

>ReD1 splay swap reason 

The debugger will now consider the new information (the file StringslmplB.bcd) and tell you what the 
signal was (String.lnvalidNumber) that caused the debugger to be called. You can now display the stack 
and run-time variables to determine what caused the uncaught SIGNAL. In the following, type what's 
underlined into the debugger: 

1. >0i splay stack - Display the first element on the run-time stack 



On line t, you asked to display the most recent call on the run-time stack. It was a procedure in 
StringslmplB, and since we are looking for our code in Function, we go on to the next item on the run-time 
stack. (The format of each line of the stack is this: procedureName, local frame pointer, moduleName, 
global FrameNumber.) 

On line 2, you asked to see the next call on the run-time stack. This time, you recognized one of your 
modules on the stack, namely "Function." You saw that the procedure being executed was procedure 
Main when a call was made to a procedure in StringslmplB. (Generally, when debugging an error like this, 
you want to keep using the "next" command until you see a procedure inyourcode.) 

On line 3, you displayed the source-code line that called the procedure in StringslmplB. It was a call 
through the String interface, and the call was to String. StringToNumber. If you look in your Pilot 
Programmer's Manual (version 12.0, p. 7-7), you will see that this procedure interprets an input string as an 
number and returns its value. 

On line 4, you inspected the variables that are local to the procedure on the stack. Notice that the string 
variable that was passed to String.StringToNumber, called number, is nil. An educated guess would be that 
this nil string caused the problem because String.StringToNumber wouldn't expect a nil string. 



2. 
3. 
4. 



>n 
>s 



- Look at the line in the source code that executed 

- Look at the local variables in this procedure 
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Your debugger should look something like this: 



go: {proceed, abort, km, screen, start} Client: {local} destroy! 

read: { } write : { } processes conflgs attach: {source, symbols} 

source! findModulel rep?! showTypet type&bitsl options! 

break: {set, clear, clearall, list, attachCond, attachKey} watch: {off} 

■ □ 

*** uncaught SIGNAL Inval IdNumber (in StrlngsImplB, G:37420B) *** 
>D1splay Stack 

No symbols for L: 14130B, PC: 4660B (in StringsImplB, G: 37420B) >n 
Main, L: 10570B, PC: 337B (1n Function, G: 112570B) >s Ocardinal «- 
String. St ringToNumber[number, 10]; 
>v 

h = 410720Bt 
clientOata = NIL 
outcome 3 normal 

OutputProc = PROCEDURE [10756B] (1n module Execlmpl, G: 35004B) 

operation = 3314464Bt( 1, 100) "q" 

number = NIL 

cardinal * 0 

answer » 0 

> 



Now you need to determine how this situation got past your error checking. In the procedure Main, the 
line immediately before the call to String.StringToNumber is: 

IF (operation * NIL) AND (number = NIL) THEN EXIT; 

Notice that operation is not nil in this case, but number is. This is the situation that should be caught because 
it produces an uncaught signal if it isn't. The correct error-catching code should be: 

IF (operation = NIL) OR (number = NIL) THEN EXIT; 

Make this change to Function. mesa. Before you can recompile your new version, you must Abort the 
current version by clicking the abort command in the Sword formSW and then unloading Function in the 
Executive. Then re-compile and run your new version. 
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More on Uncaught Signals 

This part of the exercise will show you how to stop uncaught signals from entering the debugger. Now try 
this command in the executive: 

function s/4k8 

This should cause the local debugger to be invoked with another Uncaught signal in StringslmplB. The 
signal should be String.lnvalidNumber. Now display the stack and run-time variables to determine what 
caused the uncaught signal this time. If you look at the Pilot Programmer's Manual (Ch. 7), you'll see that 
the procedure String. StringToNumber can raise the signal String.lnvalidNumber. In order to make 
Function.mesa catch the signal you need to change: 

cardinal «- String. Str1ngToNumber[number, 10]; 

to: 

cardinal «■ String. Str1ngToNumber[nuraber, 10 (String. Inval IdNumber => { 
OutputProc["Bad number. . .continuing. . . "L]; 
CONTINUE }]; 

You don't really need to understand what an uncaught signal is for now; signals will be covered in-depth 
later this week. Hopefully, what you should get out of this example is the knowledge of how to debug an 
uncaught signal. 

Remember, If you don't have the symbols for the module that raised the signal, you may want to retrieve 
them onto your machine and redisplay the reason for the swap (from the debugger). 

If you already have the symbols on your machine, you do not have to retrieve anything; the debugger will 
tell you what the uncaught signal was since it will have all the information it needs. Often, you will be able 
to debug such errors without ever retrieving the symbols: just proceed up the stack until you find one of 
your procedures, and then use the Source command to find the line of code where it died. This will often 
be enough information to enable you to debug the problem. 

Setting Breakpoints 

Now, type the following in the Executive: 

function q/ 
function s/100 
function c/100 

The answers you got for the last query should seem a little strange. 100 cubed is not 16960. At this point, it 
is a good idea to set breakpoints in the code to see why the wrong answer occasionally gets returned. To 
set breakpoints, the program must always be loaded first. Since, we have already run our program, then it 
must be loaded! 

Suppose you suspect that the variables contain the correct information, but they are not being printed out 
correctly in the procedure PrintResult. Find a local debugging window and type the underlined parts into 
the fileSW to set a breakpoint at the beginning of PrintResult: 

1. >SEt Module context: Function 

2. >Break Entry procedure: PrintResult 

3. >Proceed (Confirm) - Type a carriage return at the end of this line to confirm 
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Now try the foil owing command in the Executive: 
function c/100 

When the procedure PrintResult is entered, the breakpoint will be executed, thus causing the debugger to 
be called. In the debugger, examine the parameters for PrintResult: 

4. >Di splay Stack 

5. > E 

The value that's given to PrintResult is 16960, so the problem is not in printing out the result; the result 
itself is incorrect. Now try setting breakpoints on the procedures that actually calculate the results: 

6. >g 

7. >CLear Break §: 1 

8. >Break X1t procedure: Cubelnput 

9. >Proceed (Confirm) 

Again, try "function c/100" in the Executive. You should hit the breakpoint that you set in the procedure 
Cubelnput. (If you get a Stack Error first, just proceed and you will eventually hit your breakpoint.) Use the 
debugger to examine the return parameter (type "r" while in Display Stack mode) for Cubelnput; it should 
be equal to 1 6960. Therefore, you know that the calculation itself is incorrect. 

If you remember from the lecture this morning, multiplication of two CARDINALS will yield a CARDINAL. In 
this case, multiplying the three CARDINALS (100 and 100 and 100) resulted in an answer outside the range 
of CARDINAL (which is [0..2 16 )). The number 16960 is the modulo of (100 3 / 2 16 ).The way to fix this is to 
make the answer a LONG CARDINAL so that the overflow cases will not occur. 

You should change the following two lines of code in Function. mesa before re-compiling it and running 
Function.bcd again (remember to abort and unload before re-compiling): 

(In procedure Squarelnput..) 

RETURN [input * Input]; change to... RETURN [L0NG[1nput] * Input]; 

(In procedure Cubelnput..) 

RETURN [input • input * input]; change to... RETURN [LONG[input] * input * input]; 

"LONG" will force one of the multiplicands to be a LONG CARDINAL; hence, the answer will be a LONG 
CARDINAL because operations involving CARDINALS and LONG CARDINALS result in LONG numbers. 
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Debugger Exercises 

All of the following source files include comments at the beginning of the file explaining what the 
program does. Read those comments! Compile the programs using your favorite method and then run 
them each from the executive. Then, follow the instructions below. Each program will crash and you 
should find and fix the problem causing the crashes. Debugging techniques will be required to fix the 
programs. 

Parti: Hash. mesa 

Run the following commands from the Exec: 

Help Hash 
Hash lu mark John 
Hash john/d 
Hash john/d 

At this point, you should get an address fault. If there isn't a current local debugging session, a local 
debugging window will be created for you; otherwise, search through the active windows for the local 
debugging session. Use the debugger to your advantage. It can help you. Really! After you fix the 
problem, abort the debugging session and unload the program from the executive. Then re-compile 
and re-run your new version. Make sure that all the bugs are out by running the following commands: 

Hash lu mark 
Hash john/d 

Part II: BubbleSortProgram. mesa 

Run the following commands from the Exec: 

Help BubbleSort 

BubbleSort 2 7 4 1 10 

BubbleSort 9 7 4 12 31 16 4 28 1 32 

BubbleSort 5 18 7 22 10 11 83 22 84 24 

You should get an uncaught signal at some point. After you fix the problem, abort, unload, recompile, 
and re-run (same steps as above) and then make sure that all the bugs are out by running the following 
commands: 

BubbleSort 13 19 34 81 18 56 23 44 46 
BubbleSort 28 20 4 17 11 18 19 68 1 42 

If that input works, then try to input just one number: 
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else Put.L1ne[data.f ileSW, "undef 1ned"L] ; 
t Syntax Error [4047] 
Text inserted is: ; 

— Capitol ize ELSE 

}; 

t Syntax Error [5281] 
Text inserted 1s: ENDCASE 

-- Notice the SELECT statement. For every SELECT there should be an ENDCASE. Insert one here. 

Trial #3 

ELSE Put.L1ne[data.f ileSW, "undef ined"L]; 
t Syntax Error [4041] 
Text deleted 1s: ELSE 

There should not be a colon separating the THEN-part from the ELSE-part of the IF-THEN-ELSE 
statement. 

Trial #4 

Integer is undeclared, at Comp1lerPractice[l02l] : 

x(6): Long Integer «- 0, 
-- Again, ALL Mesa Reserved Words must be Capitol ized - so, Capitol 1ze INTEGER 

Long does not name a variant, at CompilerPract1ce[l02l]: 
x(6): Long Integer «- 0, 

— Capitol 1ze LONG 

Integer is undeclared, at Comp1lerPract1ce[l049] : 

y(8): Long Integer «- NIL] ; 
-- Capitol ize INTEGER 

Long does not name a variant, at CompilerPractice[1049]: 

y(8): Long Integer «- NIL]; 
-- Capitol ize LONG 

Trial # 5 

.NIL has incorrect type, at CompilerPractice[1049]: 

y(8): LONG INTEGER «- NIL]; 
-- A LONG INTEGER should be initialized to zero not NIL. 

Trial #6 

Command: CompilerPractice 
CompilerPract ice. mesa 

lines: 220, code: 1774, links: 22, frame: 11, time: 52 

-- After correcting all of the above errors, CompilerPractice .mesa should compile correctly! M 
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Compiler Practice Solution 

This is the .mesa file with no syntax errors. Following this listing is a listing of the compiler errors that were 
encountered and the fixes that were made. 

-- File: Compil erPracticeSol utlon .mesa - - Last edited by: 
-- MacKay 16-May-86 12:26:30 

-- Create by FormSWLayoutTool on 15-May-86 10:15A11 rights reserved. 
DIRECTORY 

Exec USING [AddCommand , ExecProc, Handle, OutputProc, RemoveCommand] , 
Format USING [StringProc], 

FormSW USING [AllocateltemDescriptor, CI IentltemsProcType, Commandltem, lineO, line2, 

LongNumberltem, ProcType], 
Heap USING [systemZone] , 
Process USING [Detach], 
Put USING [CR, Line, LongNumber, Text], 

Tool USING [Create, Destroy, MakeFileSW, MakeFormSW, MakeMsgSW, MakeSWsProc, UnusedLogName] , 
ToolWindow USING [Trans1t1onProcType], 
Window USING [Box, Handle], 
WindowFont USING [CharWidth]; 

CompllerPractice: MONITOR 
IMPORTS 

Exec, FormSW, Heap, Process, Put, Tool, WindowFont = { 

DataHandle: TYPE = LONG POINTER TO Data; 
Data: TYPE = MACHINE DEPENDENT RECORD [ 

msgSW(O): Window. Handle «- NIL, 

formSW(2): Window. Handle «- NIL, 

f1leSW(4): Window. Handle «- NIL, 

x(6): LONG INTEGER <- 0, 

y(8): LONG INTEGER «- 0]; 

Formltems: TYPE = {x, add, subtract, ytotheX, y, multiply, divide}; 

data: DataHandle «- NIL; 

wh: Window. Handle «■ NIL; 

zone: UNCOUNTED ZONE «- Heap . systemZone ; 

answer: LONG INTEGER <- 0; 

inltialBox: Window. Box = [place: [x:436, y: 82], dims: [w: 512, h: 555]]; 
busyBit: BOOLEAN <- FALSE; 

Busy: ENTRY PROCEDURE RETURNS [isBusy: BOOLEAN] = { 
ENABLE UNWIND => NULL; 
isBusy «■ busyBit; 
busyBit TRUE }; 

Done: ENTRY PROCEDURE = { 
ENABLE UNWIND => NULL; 
busyBit «■ FALSE}; 

Write: Format. StrlngProc ■ {Put.Text[data.f ileSW, s]}; 
Msg: Format. StringProc = {Put.Text[data,msgSW, s]}; 
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Add: FormSW.ProcType = { 

ENABLE ABORTED => {Done[]; CONTINUE}; 
IF Busy[] THEN { 

Msg["Tool is busy.\n"L]; RETURN}; 
Process .Detach[ FORK Addlnternal []]} ; 

Addlnternal: PROCEDURE = { 

ENABLE ABORTED => {Done[]; CONTINUE}; 
answer «• data.x + data.y; 

Put.LongNumber[data.f ileSW, data.x, [unsigned: FALSE]] 
Put.Text[data.f1leSW, « plus "L]; 

Put.LongNumber[data.f ileSW, data.y, [unsigned: FALSE]] 
Put.Text[data.f HeSW, M 1s "L]; 

Put. LongNumber[data. f HeSW, answer, [unsigned: FALSE]] 

Put.CR[data.fileSW]; 

Done[] }; 

Subtract: FormSW.ProcType = { 

ENABLE ABORTED => {Done[]; CONTINUE}; 
IF Busy[] THEN { 

Msg[ H Tool 1s busy.\n"L]; RETURN}; 
Process .Detach[FORK Subtractlnternal []]} ;; 

Subtractlnternal : PROCEDURE = { 

ENABLE ABORTED *> {Done[]; CONTINUE}; 
answer *• data.x - data.y; 

Put.LongNumber[data.f 11eSW, data.x, [unsigned: FALSE]] 
Put.Text[data.f IleSW, " minus M L] ; 

Put.LongNumber[data.f ileSW, data.y, [unsigned: FALSE]] 
Put.Text[data.f ileSW, " is " L] ; 

Put.LongNumber[data.f ileSW, answer, [unsigned: FALSE]] 
Put.CR[data.f ileSW]; 
Done[] }; 

Multiply: FormSW.ProcType = { 

ENABLE ABORTED => {Done[]; CONTINUE}; 
IF Busy[] THEN { 

Msg["Tool is busy.\n"L]; RETURN}; 
Process. Detach[FORK Multi pi ylrtternal []]};; 

Multiplylnternal : PROCEDURE = { 

ENABLE ABORTED => {Done[]; CONTINUE}; 
answer «- data.x * data.y; 

Put.LongNumber[data.f ileSW, data.x, [unsigned: FALSE]] 
Put,Text[data.fileSW, H times "L]; 

Put. LongNumber[data.f ileSW, data.y, [unsigned: FALSE]] 
Put.Text[data,f ileSW, ■ 1s "L]j 

Put.LongNumber[data.f ileSW, answer, [unsigned: FALSE]] 

Put.CR[data.f1leSW]; 

Done[] }; 

Divide: FormSW.ProcType ■ { 

ENABLE ABORTED => {Done[]; CONTINUE}; 
IF Busy[] THEN { 

Msg["Tool 1s busy.WL]; RETURN}; 
Process. Detach[ FORK Dividelnternal []]} ; 
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ENABLE ABORTED => {Done[]; CONTINUE}; 
Put.LongNumber[data.f lleSW, data.x, [unsigned: FALSE]]; 
Put.Text[data.fneSW, ■ divided by "L]; 
Put.LongNumber[data.f ileSW, data.y, [unsigned: FALSE]]; 
Put.Text[data.fileSW, " is " L] ; 
IF data.y # 0 THEN { 
answer ♦■ data.x / data.y; 

Put.LongNumber[data.f ileSW, answer, [unsigned: FALSE]]; 

Put.CR[data.f11eSW]; 

Done[];} 

ELSE Put.L1ne[data.f ileSW, "undef ined"L] ; 
Done[] }; 

YtotheX: FormSW.ProcType = { 

ENABLE ABORTED => {Done[]; CONTINUE}; 
IF Busy[] THEN { 

Msg["Tool is busy.\n"L]; RETURN}; 
Process .Detach[FORK YtotheXInternal []]} ; 

YtotheXInternal : PROCEDURE = { 

ENABLE ABORTED => {Done[]; CONTINUE}; 
IF data.x = 0 THEN answer «■ 1 
ELSE { 

answer «- data.y; 
THROUGH [1.. data.x) DO 
answer +■ answer * data.y; 
ENDLOOP;}; 

Put.LongNumber[data.f ileSW, data.y, [unsigned: FALSE]]; 
Put.Text[data.f ileSW, " raised to the power of "L]; 
Put.LongNumber[data.f ileSW, data.x, [unsigned: FALSE]]; 
Put.Text[data.f ileSW, " is "L]; 

Put.LongNumber[data.f ileSW, answer, [unsigned: FALSE]]; 

Put.CR[data.fileSW]; 

Done[] }; 

CI ientTransltlon : ToolWindow.TransitionProcType ■ { 
SELECT TRUE FROM 
old = inactive => 

IF data - NIL THEN data <- zone.NEW[Data []]; 
new a inactive => 
IF data # NIL THEN { 
zone.FREE[@data]}; 
ENDCASE; 

}; 
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-- The rest of the code 1s used for building the tool window. You will learn about this on Wednesday, 
so don't worry if you don't understand 1t. There are not any compiler errors in these procedures. 

Init: PROCEDURE = { 

Exec . AddCommand[ "Compil erPract i ce . ~ "L , NoOp, NIL, Unload]; 
wh <- Tool .Create[ 

makeSWsProc: MakeSWs, initialState: default, initialBox: inltialBox, 
cl ientTransition: CI ientTransition, name: "Comp1lerPract1ce"L, 
cmSection: "Compi 1 erPractice"L] }; 

NoOp: Exec. ExecP roc = { }; 

Unload: Exec.ExecProc = { 
IF Busy[] THEN { 

Exec.OutputProc[h]["Tool is busy. Sorry. \n"L]; 
RETURN[error] }; 
Tool .Destroy[wh] ; 

Exec.RemoveCommand[h, "CompilerPractice . ""L] ; 
Done[] }; 

MakeSWs: Tool .MakeSWsProc = { 
logName: LONG STRING ♦■ [23]; 

Tool .UnusedLogName[unused: logName, root; "CompilerPractice. log"L]; 
data.msgSW Tool .MakeMsgSW[window: window]; 
data.formSW «- Tool .MakeFormSW[ 

window: window, formProc: MakeForm]; 
data.fileSW *■ Tool .MakeFi 1 eSW[wi ndow: window, name: logName] }; 

charWidth: CARDINAL ♦- WindowFont.CharWidth[ '0]; 
CharPos: PR0C[char: CARDINAL] RETURNS [x: INTEGER] = { 
x <- charWidth * char }; 

MakeForm: FormSW.Cl ientltemsProcType = { 
OPEN FormSW; 

nltems: CARDINAL = Formltems . LAST .ORD + I; 
items ♦■ Al locateItemDescr1ptor[nItems] ; 
items[FormItems.x.ORD] ♦■ LongNumberItem[ 

tag: "X"L, place: [CharPos[l], lineO], signed: FALSE, value: Qdata.x]; 
items[FormItems .add .ORD] CommandItem[ 

tag: "ADD"L, place: [CharPos[34] , UneO], proc: Add]; 
1tems[FormItems. subtract. ORD] <- CommandItem[ 

tag: "SUBTRACT" L, place: [CharPos[47] , lineO], proc: Subtract]; 
items[FormItems.ytotheX.ORD] «- CommandItem[ 

tag: "Y to the X"L, place: [CharPos[66] , lineO], proc: YtotheX]; 
1tems[FormItems.y.0RD] LongNumberItem[ 

tag: "Y"L, place: [CharPos[l], I1ne2], signed: FALSE, value: Gdata.y]; 
items[FormItems, multiply .ORD] <- CommandItem[ 

tag: "MULTIPLY" L, place: [CharPos[34] , line2], proc: Multiply]; 
items[FormItems. divide. ORD] «- Command I tem[ 

tag: "DIVIDE"L, place: [CharPos[47] , 11ne2], proc: Divide]; 
RETURN[i terns: Items, freeDesc: TRUE] }; 

-- Mainline code 

Init[]; -- this gets string out of global frame « 
>... 
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Here is a listing of the 6 different compiler logs that it took to get the program compiled, with error 
meanings and the fixes that should be made. Keep in mind that depending on how you interpreted the 
errors, you might not get the same subsequent errors. 

Trial # 1 

DIRECTORY: 

t Syntax Error [218] 
Text deleted 1s: : 

— Just delete the colon 

Window USING [Box, Handle], 
* Syntax Error [654] 
Text deleted 1s: USING 
Text inserted 1s: ( [ 

-- Notice the line above this one. The semi-colon indicates the end of the DIRECTORY clause, which 
shouldn't end here. The semi-colon should be replaced with a comma. 

WindowFont USING [CharWidth] ; 

t Syntax Error [688] 
No recovery found. 

— This error was caused by the misplaced semi-colon, also. When that correction is made, this error 
will go away. 

Trial #2 

Exec, FormSW, Heap, Process, Put, Tool, WindowFont, = { 

t Syntax Error [799] 

Text inserted is: id 

-- Delete the comma following "WindowFont" 

Put.Text(data.fileSW, " plus "L); 
t Syntax Error [2025] 
Text deleted is: ( id . id , 
Text Inserted is: ; ( 

-- Replace the opening AND closing parentheses with square brackets. 

Put.CR(data.fileSW); 

t Syntax Error [2217] 
Text inserted is: ; 
-- Same error as above 

if data.y 0 0 then { 
t Syntax Error [3890] 
Text Inserted 1s: _ 

The problem here is caused from 'If not being 1n caps, so the compiler doesn't recognize it as a 
reserved word. Solution: capltollze IF 
if data.y ft 0 then { 

t Syntax Error [3901] 
Text deleted is: id 
Text inserted 1s: ; 
-- Capitalize THEN 
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Solutions to Debugger Exercises 

Part I: Hash. mesa 

An address fault occurs when you are searching for an element to be deleted and the element is not in 
the list. To fix this error, add some error checking to make sure that the element is in the list before you 
try to delete it. 

DeleteRec: PROCEDURE [string: LONG STRING «- NIL] RETURNS [BOOLEAN «- TRUE] = BEGIN 
ptr, ptr2: Handle; 
bucket: CARDINAL; 
[ptr, bucket] «- F1ndRec[string]; 
IF ptr - NIL THEN RETURN[ FALSE]; 
ptr2 ♦■ tab1e[bucket]; 

UNTIL (ptr2.myS1bling = NIL) OR (ptr2 .mySibl ing » ptr) DO 

ptr2 «- ptr2.myS1bling; 
ENDLOOP; 

IF ptr2.myS1bling = ptr THEN BEGIN 
ptr2.myS1bl ing «- ptr.mySibl ing; 
RETURN[TRUE] ; 
END 

ELSE RETURN[FALSE] ; 
END; 

Part II: BubbleSortProgram.mesa 

An Uncaught Signal (BoundsFault) occurs because the comparision statement in the FOR loop tries to 
access one node larger than the allocated array size. This was caused by a square bracket (which is 
inclusive) instead of a parenthesis (which is exclusive) in FOR statement. 

DoTheBubbleSort: PROCEDURE [upperBound :CARDINAL] RETURNS [BOOLEAN, CARDINAL] = 
BEGIN 

oxchangeMade: BOOLEAN «- FALSE; 
position: CARDINAL «- 0; 
FOR j: CARDINAL IN [0. .upperbound-1) DO 
IF A[j] > A[j +1] THEN { 

InterChange[j, j+1]; 

position «- j ; 

oxchangeMade «- TRUE; 

}: 

ENDLOOP ; 

RETURN[exchangeMade, position]; 
END; --DoTheBubbleSort 



Note: The range [0. .upperbound-2] will not work when upperbound < 2. 
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Program Example 



| Math Tool 




First Nu«ber= 22 



Second Number 3 17 



Product 1 



Sua! 



Difference! 



Quotient! 



The product of 22 and 17 is 374 
The sum of 22 and 17 is 39 
The difference of 22 and 17 is 5 
The quotient of 22 and 17 is 1 



--Math .mesa 
--John Erskine 
--14-Dec-84 17:30:08 

DIRECTORY 

Window USING [Handle]; 

Math: DEFINITIONS = 

BEGIN 

Add: PROCEDURE [output: Window. Handle, nl, n2: INTEGER]; 
Divide: PROCEDURE [output: Window. Handle, nl, n2: INTEGER]; 
Multiply: PROCEDURE [output: Window. Handle, nl, n2: INTEGER]; 
Subtract: PROCEDURE [output: Window. Handle, nl, n2: INTEGER] ; 



END.. 
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— MathControl .mesa - Last Edited on: 

— 13-Aug-87 13:19:23 

-- Create by FormSWLayoutTool on 12-Aug-87 17:57 
DIRECTORY 

Exec USING [AddCommand, ExecProc, OutputProc, RemoveCommand] , 
Format USING [StringProc] , 

FormSW USING [Al locateltemOescriptor, CI lentltemsProcType, Commandltem, lineO, line2, 

LongNumberltem, ProcType], 
Heap USING [Create], 

Math USING [Add, Divide, Multiply, Subtract], 

Process USING [Detach], 
Put USING [Text], 

Tool USING [Create, Destroy, MakeFileSW, MakeFormSW, MakeMsgSW, MakeSWsProc, UnusedLogName] , 
ToolWIndow USING [TransitionProcType] , 
Window USING [Handle]; 

MathControl: MONITOR 
IMPORTS 

Exec, FormSW, Heap, Math, Process, Put, Tool ■ { 

DataHandle: TYPE = LONG POINTER TO Data; 
Data: TYPE * MACHINE DEPENDENT RECORD [ 

msgSW(O): Window. Handle «- NIL, 

formSW(2): Window. Handle «- NIL, 

fileSW(4): Window. Handle «■ NIL, 

firstNumber(6): LONG INTEGER «- 0, 

secondNumber(8): LONG INTEGER - 0]; 

Formltems: TYPE = {f 1 rstNumber , secondNumber , sum, difference, product, quotient}; 

data: DataHandle «- NIL; 
wh: Window. Handle *• NIL; 

myZone: UNCOUNTED ZONE «- Heap .Create[in1t lal : 4]; 
busyBit: BOOLEAN «- FALSE; 

Busy: ENTRY PROCEDURE RETURNS [isBusy: BOOLEAN] » { 
ENABLE UNWIND «> NULL; 
isBusy *■ busyBit; 
busyBit <- TRUE }; 

Done: ENTRY PROCEDURE = { 
ENABLE UNWIND -> NULL; 
busyBit «■ FALSE }; 

Write: Format .StringProc = {Put.Text[data.f ileSW, s]>; 

Msg: Format. StringProc = {Put.Text[data.msgSW, s]}; 

Sum: FormSW. ProcType = { 

ENABLE ABORTED -> {Done[]; CONTINUE}; 
IF Busy[] THEN { 

Msg["Tool is busy.\n"L]; RETURN}; 
Process .Detach[FORK Sumlnternal []]} ; 
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Sumlnternal : PROCEDURE = { 

ENABLE ABORTED => {Done[]; CONTINUE}; 

Mat h.Add[ data. flleSW, data.f 1rst Number, data. secondNunber]; 

Done[] }; 

Difference: FormSW.ProcType 3 { 

ENABLE ABORTED -> {Done[]; CONTINUE}; 
IF Busy[] THEN { 

Msg["Tool is busy.\n"L]; RETURN}; 
Process. Detach[FORK D1f ferencelnternal []]} ; 

Dlfferencelnternal : PROCEDURE =« { 

ENABLE ABORTED -> {Done[]; CONTINUE}; 

Math . Sub t ract [ data . f 11 eSW , data . f 1 rs tNumbe r , data . secondNumbe r ] ; 

Done[] }; 

Product: FormSW.ProcType = { 

ENABLE ABORTED •> {Done[]; CONTINUE}; 
IF Busy[] THEN { 

Msg[ n Tool is busy .\n"L]; RETURN}; 
Process .Detach[FORK Productlnternal []]} ; 

Productlnternal : PROCEDURE = { 

ENABLE ABORTED => {Done[]; CONTINUE}; 

Math. Mul t1 ply [data. fileSW, data.f 1rs tNumbe r, data. secondNumbe r]; 

Done[] }; 

Quotient: FormSW.ProcType = { 

ENABLE ABORTED => {Done[]; CONTINUE}; 
IF Busy[] THEN { 

Msg[ M Tool 1s busy.\n"L]; RETURN}; 
Process. Detach[ FORK Quot1entInternal[]]}; 

Quotientlnternal : PROCEDURE = { 

ENABLE ABORTED -> {Done[]; CONTINUE}; 

Math.D1v1de[data.f1leSW, data.f Irs tNumbe r, data.secondNumber]; 

Done[] }; 



CI 1entTransit1on: ToolW1ndow.Trans1t1onProcType = { 
SELECT TRUE FROM 
old ■ inactive *> 

IF data = NIL THEN data «- myZone .NEW[Data *• []]; 
nev»:= Inactive *> 

IF data # NIL THEN myZone. FREE[9data] ; 
ENDCASE; 

> ; " :■ 

In1t: PROCEDURE = { 

Exec . AddCommand[ "MathTool . ~ H L, NoOp, NIL, Unload]; 

wh *■ Tool .CreateC 

makeSWsProc: MakeSWs, initialState : default, 

cl ientTransltion: CI 1entTrans1t1on, name: "MathTool "L, 

cmSectlon: "MathTool "L] ; 

>; 
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NoOp: Exec.ExecProc = { }; 

Unload: Exec.ExecProc ■ { 
IF Busy[] THEN { 

Exec.OutputProc[h]["Tool is busy. Sorry. \n"L]; 

RE TURN[ error] }; 
Tool .Destroy[wh] ; 

Exec.RemoveCommand[h, "MathTool . ~"L]; 
Done[] }; 

MakeSWs: Tool .MakeSWsP roc s { 
logName: LONG STRING - [15]; 

Tool . UnusedLogName[unused: logName, root: "MathTool . log" L] ; 
data.msgSW «- Tool .MakeMsgSW[ window: window]; 
data.formSW «- Tool .MakeFormSW[ 

window: window, formProc: MakeForm, zone: myZone]; 
data.fileSW «- Tool .MakeFi leSW[window: window, name: logName]; 

> ; 

MakeForm: FormSW.Cl ientltemsProcType - { 
nltems: CARDINAL = FormI terns. LAST. ORD + 1; 
items «- FormSW.Al locateItemDescriptor[nItems, my Zone]; 
i tems[FormI terns. firstNumber. ORD] «- FormSW.LongNumberItem[ 

tag: "First Number"L, place: [6, FormSW.lineO], signed: FALSE, 

value: Qdata. firstNumber, z: myZone]; 
items[FormI terns. secondNumber. ORD] «■ FormSW.LongNumberItem[ 

tag: "Second Number"L, place: [186, FormSW.lineO], signed: FALSE, 

value: Qdata. secondNumber, z: myZone]; 
items[FormI terns, sum. ORD] «- FormSW. Command I tem[ 

tag: "Sum"L, place: [6, FormSW. 1 ine2] , proc: Sum, z: myZone]; 
items[FormItems. difference. ORD] «- FormSW. Command I tem[ 

tag: "Dif ference"L, place: [90, FormSW. 1 ine2] , proc: Difference, z: myZone]; 
items[ FormI terns .product .ORD] ♦■ FormSW. CommandItem[ 

tag: "ProducfL, place: [188, FormSW. 1 ine2], proc: Product, z: myZone]; 
items[FormI terns . quotient. ORD] ♦• FormSW. Command I tem[ 

tag: "Quotienf'L, place: [294, FormSW. 1 ine2], proc: Quotient, z: myZone]; 
RETURN[i terns : items, freeDesc: TRUE]; 

}; 



— Mainline code 

Init[]; — t^his gets string out of global frame 
>... 
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--Mathlmpl .mesa 

— John Ersklne 

— 14-0ec-84 17:40:29 

DIRECTORY 

Window USING [Handle], 

Put USING [CR, Decimal, Text], 

Math; 

Mathlmpl : PROGRAM IMPORTS Put EXPORTS Math = { 

Add: PUBLIC PROCEDURE [output: Window. Handle, nl, n2: INTEGER] = { 
Put.Text[output,"The sum of H L]; 
Put .Decimal [output.nl] ; 
Put.Text[output," and "]; 
Put. Decimal [output, n2]; 
Put.Text[output," is "L]j 
Pu t. Decimal [output, n l+n2 ] ; 
Put.CR[output]; 

}; 

Divide: PUBLIC PROCEDURE [output: Window. Handle, nl, n2: INTEGER] = 
Put.Text[output,"The quotient of "L] ; 
Put. Decimal [output.nl]; 
Put.Text[output, " and "]; 
Put. Decimal [output, n2] ; 
Put.Text[output, H is "L]; 
IF n2 = 0 THEN 

Put . Text[outpu t , " 1 nf 1 n i ty " ] 

ELSE 

Put . Decimal [output , n l/n2] ; 
Put.CR[output]; 

}; 

Multiply: PUBLIC PROCEDURE [output: Window. Handle, nl, n2: INTEGER] 
Put.Text[output, "The product of "L]; 
Put .Decimal [output.nl] ; 
Put.Textfoutput," and "]; 
Put. Decimal [output, n2]; 
Put.Text[output, " is H L]; 
Put. Decimal [output, nl*n2]; 
Put.CR[outp«t]; 

}; 

Subtract: PUBLIC PROCEDURE [output: Window. Handle, nl, n2: INTEGER] 
Put.Text[output,"The difference of M L] ; 
Put.Dec1mal[output,nl] ; 
Put.Text[output," and "]; 
Put. Decimal [output, n2]; 
Put.Text[output, " 1s "L]j 
Put. Decimal [output, nl-n2]; 
Put.CR[output]; 

}; 

}... 
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--MathTool .conf 1g 

--John Erskine 

— 14-Dec-84 17:49:17 

MathTool : CONFIGURATION 

IMPORTS Exec, FormSW, Heap, Tool, Process, Put 

CONTROL MathControl =■ { 

MathControl ; 
Mathlmpl ; 

}... 
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In Class Exercise - Configurations 

Write a CONFIGURATION file for a program consisting of the files shown below. (The bold-lined boxes are 
PROGRAM modules and the dotted-lined boxes are DEFINITIONS modules.) 

Note: Just write one configuration file for the entire application instead of a nested config within a config. 



PrivAlmpI: program 
exports PrivDefs ■ 

BEGIN 
END. 



PrivBlmpI: program 
exports PrivDefs ■ 

BEGIN 
END. 




PrivDefs: definitions 

BEGIN 
END. 




Publiclmpl: program 
imports FormSW, PrivDefs, String 
exports PublicDefs ■ 

BEGIN 
END. 



j Heap: definitions ■ j 

: BEGIN 
j END. 



J 

PublicDefs: definitions ■ 

BEGIN 
END. 



I String: definitions * 

j BEGIN 
: END. 



"' • * t A-'"" 



PublicClient: program 
imports Heap, PublicDefs, String ■ 

BEGIN 

- mainline code 

END. 
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Interfaces Programming Assignment: Turtle 

In this programming assignment, you need to provide the implementation of one interface using 
procedures defined in another interface. The finished product will implement the Turtle programming 
language: 

Initially, a turtle is located at the top left-hand side of the window (coordinates 0, 0). This turtle carries a 
pen. You can tell the turtle to move different distances and different directions with his pen either 
lowered or raised by clicking the appropriate commands. While the pen is lowered, you will see the turtle 
leave a trail behind him as he moves. 




The interface you will be implementing is called Turtle.mesa: 

-Turtle.mesa 
-2-Oct-84 11:14:51 

DIRECTORY 

Window USING [Handle]; 

Turtle: DEFINITIONS - { 

gridSize: cardinal =» 32; ~ length and width of grid 

Horn: PROCEDURE [output: Window. Handle] ; ~ Puts turtle at (0,0) 

PenUp: procedure; - Raises the pen. 

PenDown: procedure; - Lowers the pen. 

Move: PROCEDURE [output: Window. Handle, distance: CARDINAL, direction: [0 .. 8)]; 

- Moves the turtle by the amount in distance in the given 

-- direction. 0 is up (North), 1 is up 1 and right 1 (NorthEast), 

- 2 is to the right (East), . . . 

Erase: PROCEDURE [output: Window. Handle] ; - Completely dears the grid. 

Redraw: PROCEDURE [output: Window. Handle] ; 

~ Draws the grid from scratch when the window becomes active 

}. 
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You need to write an implementation module, TurtleSmpI mesa, that implements the procedures listed 
above. These procedures get called from the module TurtleControl.mesa when the user invokes the 
appropriate commands in the form subwinclow. (Redraw is called when the user changes the size of the 
window. For example, Redraw will be called if you make the Turtle window tiny and then reactivate it,,) 
You don't have to actually write the code that draws the boxes on the screen; instead, you should import 
procedures from the Boxes interface to do the actual drawing: 

-Soxes, mesa 

DIRECTORY 
Window USING [Handle]; 

Boxes: DEFINITIONS - { 

DrawWhlte: PROCEDURE [output: Window. Handle, y, x; CARDINAL] ; 
DrawGray: PROCEDURE [output: Window. Handle, y, x: CARDINAL]; 
DrawBlack: PROCEDURE [output: Window. Handle, y, x; CARDINAL] ; 

}• 

These procedures will draw a box at the coordinates (y,x). [(0,0) is the top left-hand corner of the window 
shown in the tool, x increases to the right and y increases downward.] The implementation for the Boxes 
interface has already been written and is provided in the module Boxeslmpl.mesa. 

Note that the procedures Home, Move, Erase, and ReOraw are all passed in a parameter of type 
Window. Handle This parameter is used to specify the window in which the painting is to be done. 
(Basically, it is just a pointer to the proper subwindow.) You don't have to do anything with this parameter 
except pass it along to the routines in Boxes. (Those routines need to know where to do the painting.) 

In your implementation module, you will need a 2-dimensional packed array of BOOLEANs in order to 
determine where the turtle has been. The length of each dimension should be indicated by the constant 
gridSiie in the interface Turtle.mesa. You'll have to keep track of whether the pen is up or down and 
where the turtle is at any given time. Your implementation should handle the case where the user instructs 
the turtle to go off the edge of the grid (outside the bounds of the array). Simply not moving is the easiest 
implementation. When the pen is down, everytime the turtle moves off a square, that square should be 
marked with a gray box. When the pen is up, the square should remain in its original condition. 

Assignment 

1. Write the implementation module TurtlelmpLmesa that implements the procedures in 
Turtle.mesa. 

2. Write the configuration file TurtleTool.config. 

3. Verify that your implementation is correct by running the tool. 
Extra for Experts 

In your implementation module TurtlelmpLmesa, change the implementation for the procedure Home 
so that when Home is called, the turtle will recursively look for a path home from his current position, 
and mark that path with all black squares. Limit the turtle to only the gray squares that up to this point 
have marked his wanderings. Allow for the possibility that there may not be a path home in which case 
you may either place the turtle home or leave him in his current position. When testing this extension, 
you may want to increase the constant giridSize in the definitions module Turtle.mesa. 



-- Draws a white box 
— Draws a gray box 
~ Draws a black box 
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Tool-Written Factorial Tool 









□ 

Number = Format: (hex, octal, decimal} 
Factorial! 




The factorial of 4 is 24 



-- Factorial Tool .mesa 

-- Create by FormSWLayoutTool on 18-May-86 10:42 

DIRECTORY 
Exec, 
Format, 
FormSW, 
Heap, 
Process, 
Put, 
Tool , 

ToolWindow, 
Window; 

FactoMalTool : MONITOR IMPORTS Exec, FormSW, Heap, Process, Put, .Tool = { 

DataHandle: TYPE = LONG POINTER TO Data; 
Data: TYPE > MACHINE DEPENDENT RECORD [ 

msgSW(O): Window. Handle <- NIL, 

formSW(2): Window. Handle «■ NIL, 

fileSW(4): Window. Handle «- NIL, 

number(6): UNSPECIFIED «- 0, 

format(7): UNSPECIFIED «■ 0]; 

Formltems: TYPE ■ {number, format, factorial}; 

data: DataHandle «- NIL; 
wh: Window. Handle «- NIL; 

zone: UNCOUNTED ZONE Heap.Create[initial : 4]; 
busyBit: BOOLEAN <- FALSE; 

Busy: ENTRY PROCEDURE RETURNS [isBusy: BOOLEAN] = { 
ENABLE UNWIND => NULL; 
isBusy *• buSyBit; 
busyBit «- TRUE }; 

Done: ENTRY PROCEDURE = { 
ENABLE UNWIND => NULL; 
busyBit *■ FALSE }; 

Write: Format. StrlngProc * {Put .Text[data.f 1leSW, s]}; 
Msg: Format .StringProc ■ {Put . Text[data.msgSW, s]}; 
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Factorial: FormSW.ProcType = { 

ENABLE ABORTED => {Done[]; CONTINUE}; 

IF Busy[] THEN { Msg["Tool is busy.WL]; RETURN}; 

Process. Detach[FORK Factorial Internal []]} ; 

Factorial Internal : PROCEDURE * { 

ENABLE ABORTED => {Done[]; CONTINUE}; 
Wr1te[ H Factor1al cal led\n"L] ; 
Done[] }; 

CI ientTransition : ToolWindow.TransltionProcType ■ { 
SELECT TRUE FROM 

old =» inactive »> IF data ■ NIL THEN data «• zone.NEW[Data <- []]; 
new = inactive ■> IF data # NIL THEN { zone. FREE[9data] }; 
ENDCASE }; 

Init: PROCEDURE - { 

Exec. AddCommand[" Factorial Tool . ""L, NoOp, NIL, Unload]; 

wh *• Tool .Create[makeSWsProc: MakeSWs, initialState: default, 

cl ientTransition : CI ientTransition , name: "FactorlalTool "L, cmSection: "FactorlalTool H L] }; 

NoOp: Exec. ExecP roc ■ { }; 

Unload: Exec .ExecProc * { 
IF Busy[] THEN { 
Exec.OutputProc[h]["Tool is busy. Sorry An"L]; 
RETURN[error] }; 
Tool .Destroy[wh] ; 

Exec.RembveCommand[h, "FactorialTool . ""L]; 
Done[] }; 

MakeSWs: Tool .MakeSWsProc * { 
logName: LONG STRING *■ [20]; 

Tool .UnusedLogName[unused: logName, root: "FactorlalTool . log H L] ; 
data.msgSW «- Tool .MakeMsgSW[w1ndow: window]; 

data.formSW Tool .MakeFormSW[w1ndow: window, formProc: MakeForm]; 
data.fileSW <- Tool .MakeF1leSW[window: window, name: logName] }; 

MakeForm: FormSW.Cl lentltemsProcType = { 
OPEN FormSW; 

nltems: CARDINAL = Forml terns. LAST. ORD + 1; 
format: ARRAY[0..3) OF Enumerated [ 

["hex H L, 0], ["octal M L, 1], ["decimal "L, 2]]; 
items *■ AllocateItemDescriptor[nItems] ; 
1tems[FormI terns. number. ORD] *■ Numberltem[ 

tag: "Number"L, place: [6, lineO], signed: FALSE, notNegative: TRUE, value: Sdata. number] ; 
1tems[FormI terns. format. ORD] Enumeratedltem[tag: "Format"L, 

place: [186, lineO], feedback: all, choices: DESCRIPTOR[format], value: Odata. format]; 
items [Forml terns . factorial .ORD] *■ CommandItem[ 

tag: "Factorial "L, place: [6, Unel], proc: Factorial]; 
RETURN[1 terns; items, freeDesc: TRUE] }; 

— Mainline code 

Init[]; -- this gets string out of global frame 
}... 
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User-Modified Factorial Tool 

— FactorialTool .mesa 

-- Create by FormSWLayoutTool on 16-May-86 10:42. Modified on 16-May-86 10:57 
DIRECTORY 

Exec USING (AddCommand, ExecProc, Handle, OutputProc, RemoveCommand] , 
Format USING [StringProc] , 

FormSW USING [Allocatettem Descriptor, ClientltemsProcType, Commandltem, Enumerated, 

Enumeratedltem, lineO, linel, Numberltem, ProcType], 
Heap USING [Create! , 
Process USING [Detach J , 
Put USING [TextJ , 

Tool USING [Create, Destroy, MakeFileSW, MakeFormSW, MakeMsgSW, MakeSWsProc, UnusedLogNameJ , 
Tool W1 ndow USING [TransitionProcType] , 
Window USING [HandleJ; 

FactorialTool: MONITOR IMPORTS Exec, FormSW, Heap, Put, Process, Tool » { 

DataHandle: TYPE = LONG POINTER TO Data; 
Data: TYPE - MACHINE DEPENDENT RECORD [ 

msgSW(O): Window. Handle «- NIL, 

formSW(2): Window. Handle <- NIL, 

f1leSW(4): Window. Handle «- NIL, 

number(6): CARDINAL «- 0, 

f o rma t ( 7 ) : FormatType *- decimal'] ; 

FormatType: TYPE = (hex. octal, decimal}; 
Formltems: TYPE = {number, format, factorial}; 
data: DataHandle «- NIL; 
wh: Window. Handle «■ NIL; 

zone: UNCOUNTED ZONE «- Heap.Create[1nit1al : 4]; 
busyBU: BOOLEAN ♦■ FALSE; 

Busy: ENTRY PROCEDURE RETURNS [isBusy: BOOLEAN] =■ { 

ENABLE UNWIND => NULL: 

IsBusy «- busyBU; 

busyBU «- TRUE }; 
Done: ENTRY PROCEDURE =» { 

ENABLE UNWIND »> NULL: 

busyBU «- FALSE }; 

Write: Format .StringProc = {Put.Text[data.f ileSW, s]}; 
Msg: Format .StringProc s {Put.Text[data.msgSW, s]>; 

CI ientTransltlon: ToolWindow. TransitionProcType - { 
SELECT TRUE -FROM 

old ■ inactive »> IF data ■ NIL THEN data «■ zone.NEW[Data «■ []]; 
new = inactive => IF data # NIL THEN { zone. FREE[8data] }; 
ENDCASE }; 

Factorial: FormSW. ProcType = { 

ENABLE ABORTED => {Done[]; CONTINUE}; 

IF Busy [] THEN { Msg["Tool 1s busy.\n"L]; RETURN}; 

Process . Detach[FORK Factori al Internal []} ; 
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Factorial Internal : PROCEDURE = { 

ENABLE ABORTED => {Done[]; CONTINUE}; 
IF data.number > 12 THEN { -Out of range. 

Put,CR[data.msgSW]; PutTextldata.msgSW, "Too high, try agaln."L] } 
ELSE { 

result: LONG CARDINAL *- 1; 
temp: CARDINAL <t— data.number; 

WHILE temp > 0 DO result +- result * temp; temp*- temp - 1; ENDLOOP; 
PuLCR[data.fileSWj; 

PutText[dataJileSW, "The factorial of "]; 
PutDecimalldata.fileSW, data.number]; 
Put.Textldata.meSW, "is "]; 
SELECT data Jormat FROM 

hex = > PutLongNumber[data.fileSW, result [16]]; 

octal a > PutLongNumberldata.fileSW, result, [8]J; 

decimal =» > PutLongNumberldata.fileSW, result, [10]]; 

ENDCASE; 
PutCR[data.fileSW] }: 
Done[]}; 

Init: PROCEDURE = { 

Exec. AddCommandC" Factorial Tool „~"L. NoOp, NIL, Unload]; 

wh «• Tool .Create[makeSWsProc: MakeSWs, initialState: default, 

cl ientTransition: CI 1entTrans1t1on , name: " Factorial Tool "L, cmSection: "Factorial Tool "L] }; 

NoOp: Exec. ExecP roc ■ { }; 

Unload: Exec.ExecProc 3 { 
IF Busy[] THEN { 

Exec.OutputProc[h]["Tool is busy. Sorry. \n"L]; 
RETURN[error] }; 
Tool .Destroy[wh] ; 

Exec.RemoveCommand[h, "Factorial Tool .~ M L]; 
Done[] }; 

MakeSWs: Tool .MakeSWsProc = { 
logName: LONG STRING - [20]; 

Tool .UnusedLogName[unused : logName, root: "FactorlalTool .log"L]; 
data.msgSW *■ Tool .MakeMsgSW[w1ndow: window]; 

data.formSW Tool .MakeFormSW[w1ndow: window, formProc: MakeForm]; 
data.fileSW Tool .MakeF1leSW[window: window, name: logName] }; 

MakeForm: FormSW.Cl lentltemsProcType - { OPEN FormSW; 
n I terns-: CARDINAL = Fo rml terns . LAST .ORD + 1; 

format: ARRAY[0..3) OF Enumerated «- [[ M hex n L, 0], ["octal-L, 1], ["decimal "L, 2]]; 
Items «• Al Iocateltem0escr1ptor[nltems] ; 
1tems[Formitems. number. ORD] <- Numberltem[ 

tag: H Number"L, place: [6, lineO], signed: FALSE, notNegative: TRUE, value: Sdata. number]; 
i tems[FormI terns. format. 0R0] Enumeratedltem[tag : "Format"L, 

place: [188, UneO], feedback: all, choices: DESCRIPTOR^ ormat] , value: Qdata. format] ; 
1 terns [Forml terns . factorial .ORD] *■ Command I tem[ tag: "Factorial "L, place:[8, linel], proc: Factorial]; 
RETURN[i terns: items, freeDesc: TRUE] }; 

In1t[]; "-- this MalnLine code gets the string out of global frame 

}... 
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Using the FormSWLayoutTool 

Description 

The FormSWLayoutTool has three subwindows: a message subwindow, a form subwindow, and a file 
subwindow. The items in the FormSWLayoutTool form subwindow are as follows: 

FormType: {boo I, command, enum, longNum, num, source, string, tag} 

This is an enumerated item that lists the possible items that you can have in a form subwindow. When 
you are laying out a form subwindow, you select the type of the item that you want from this 
enumeration. 



bool 



creates a Mesa BOOLEAN, and is video inverted when TRUE. 



command creates a command with an associate procedure that will be called when the command is 
invoked. 

enum creates a tag containing an enumerated list of items. The code generated does not use 
Mesa enumerated types; rather it creates an ARRAY DESCRIPTOR containing strings 
corresponding to the names in the enumerated tag, and cardinal numbers that correspond 
to the ORD of the tag item. 

longNum generates a LONG UNSPECIFIED, which you can change to a LONG CARDINAL or LONG 
INTEGER. 



num generates an UNSPECIFIED, which you can change to a CARDINAL or INTEGER, 
source is not currently supported. 

string creates a LONG STRING and in the code sets it to NIL. 

tag does not generate a Mesa variable; it simply creates the named tag and places it on your 

tool. The tag has no functionality; it is for documentation/information. 

Tag: This is where you type the name of the tag for the item that you want to place in your form 
subwindow. Thus, if you want your new form subwindow to have a command called Fred!, you 
would put Fred in the Tag: field and select Command from the FormType enumeration. 

Zone: This specifies the heap that you want your program to use for storage allocation. If you leave 
this field blank, the default is to use the systemZone. 

AlignX is a boolean that causes columns to be defined by the width of the character '0. If you don't use 
this option, the default is to define one column per bit on the screen. You should use AlignX to 
ensure that you have straight columns, since it may be difficult to discern if a column is off by 
one bit. 

Usebox causes the generated tool to have the same dimensions and location as the 
FormSWLayoutTool. Thus you simply manipulate the layout tool to the size and position you 
like and your new tool will have the same characteristics. Obviously, this only controls the initial 
size and position of the tool; the user is free to change the window. 

Anyfont causes the layout tool to generate code that will have proportional spacing rather than 
absolute. This means that the form subwindow will look right regardless of the font that the 
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user chooses. Otherwise, if the tool is displayed in a large font, the letters may distort and 
overlap. 

Root: is where you specify the name that you want your source file to have. Don't include the .mesa 
extension; this is added automa tically by the tool. 

Dolt! causes the layout tool to generate code for the form subwindow. 

SetDefaults! allows you to set the defaults for the property sheets of the different form items. 

Save! saves the contents of the form subwindow that you are creating in a file named root .by. This 
can be useful if you are creating a complex tool and want to ensure that a system crash won't 
destroy your work. 

Load! loads a .by file into the layout tool so you can continue work (the .by is automatically 
appended onto the root.) 

Plagiarize! lets you copy a form subwindow from another tool into the layout tool's window. Just invoke 
Plagiarize! and then select the form subwindow that you want to plagiarize. You can then edit 
the plagiarized window, as described below. 



Operation 

The layout tool has two modes of operation:: initial layout and editing. When there is text in the Tag: field, 
you are in initial layout; otherwise, you are editing. 

When you are in initial layout mode, the mouse pointer becomes a brush (a string of characters that 
represents the tag). To add an item to your new form subwindow, select the type of the item from the 
FormType enumeration, put the appropriate tag in the Tag: field, move the mouse into the bottom 
subwindow and click over the desired location. When you are through laying out your new form 
subwindow, remove the text from the Tag: field and you are ready to edit the form. 

In edit mode, you can use the DELETE, MOVE, COPY and PROPS keys to edit the items in your form 
subwindow. DELETE, MOVE, and COPY have the obvious meanings; PROPS allows you to change the 
properties of an item. Each form item that you create has associated properties, which you can display by 
selecting the item and pressing the PROP'S key on your keyboard. You can use this property sheet to 
change various aspects of the item, such as the name of the Mesa variable that an item represents. When 
you create an enumerated item, you will have to use the property sheet to set the values that the 
enumeration can have. 
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Dynamic Storage Allocation Exercise: Letter Groups 

In this exercise, you will complete a program that takes a string of characters as input and stores the 
characters alphabetically in queues according to the number of queues that the user specifies. For 
example, if the input were James! Where are you?!, and the user wanted four groups of characters, the 
result would look like this: 



For Group 0(A-G): 
a e e e a e 



For Group 1 (H-N): 
J m h 

For Group 2 (O-T): 
s r r o 

For Group 3 (U-Z): 
W y u 

For Last Group (non-alphabetic characters): 
I SP SP SP ? ! 

Done. 



The program runs from a tool, which consists of the following files: 



LetterControl.mesa: 
Letterlmpl.mesa: 
LetterOefs.mesa: 
LetterTool.config: 



contains tool-related code (I/O); 

contains the implementation code that actually processes the input; 

is the interface for this tool; 

is the configuration module for the above. 



Input: James 1 Where are you?! 
Nuaber of Queues: {four} 
Group! 



For Group 0 (A-6): 

a e e e a e 

For Group 1 (H-N) : 
J m h 

For Group 2 (0-T): 
s r r o 



The tool as it appears when LetterTool.bcd is executed. 
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When the user invokes Group!, the Commandltem procedure Group (in LetterControl) passes the input 
string and desired the number of queues to procedure Processlnput (in Letterlmpl). Processlnput calls five 
procedures: InitQueues, CutUpAlphabet, StoreLetters, PrintResults, and DeallocateQueues. InitQueues 
creates and initializes the queues; CutUpAlphabet determines which characters in the alphabet each 
queue will handle; StoreLetters actually puts the characters into the queues; PrintResults (in 
LetterControl) displays the results; and DeallocateQueues deallocates the storage that the queues used. 

There are two instances where dynamic storage allocation must be considered. First, there is the initial 
allocation from a heap, where two factors are variable: the number of queues and the size of each queue. 
Secondly, there is the expansion of a queue when the sequence that represents the queue is full. The 
"expansion" really consists of allocating a new sequence that is larger than the original one, copying over 
the original sequence into the new one, inserting the new sequence in place of the original one, and 
freeing the space that the original sequence occupied. 

Assignment 

Modify the file Letterlmpl. mesa and fill in the dynamic storage allocation code in the indicated places. The 
procedures that you need to write are listed at the top of the Letterlmpl. mesa. You will need to use some 
of the types that are declared in Letter Defs. mesa. 
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Extra Programming Assignment: Editor 

In this exercise, you will modify a line editor that runs in a tool window. To use this tool, you use the Enter 
Input! command to enter input in the line editor, and then use the other commands to change that input. 





: □ 




Input: 

Line Number = 0 

Enter Input! Load Line Number! Redisplay Text! Delete Line! 
Find! <-: 
Replace! «-: 

n 







The line editor currently calls the following string manipulation procedures in the String interface: 

Stri ng .CopyToNe wStr i ng 
String. DeleteSubString 
String. Equal Substring 
String.ExpandString 
String. FreeString 
String. I nsertString 
String. Replace 

Your assignment is to implement the same procedures through another interface called String2. We have 
provided the interface; you need to write the implementations to this new interface and bind the modules 
together into a configuration. 

You will need the following modules for this assignment: 

EditorDefs.mesa 
Editorlmpl.mesa 
EditorTool.mesa 
Stri ng2. mesa 
Editor2.config 
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Before you start writing your implementation module, you might want to run the working version 
(Editor.bcd) to get an idea of how it works. Once you are ready to start writing code, you need to do the 
following: 

1) Change all String references to String2 in the module Editorlmpl. 

2) Create an implementation module for String2 (Name it String2lmpl.mesa). 

3) Move the procedure InsertString from the module Editorlmpl to St ring 21m pi. mesa. 

4) Change all InsertString references to String2.lnsertString. 

5) Write the implementations for the procedures listed in String2. 

6) Change the configuration Editor2.config to reflect the new usage of program modules. 

7) Test your program. 

Note that in order to write the implementations for the String2 procedures, you will have to read the 
String documentation in the Pilot Programmer's Manual to get an idea of what the procedures are 
supposed to do, and how a substring works. 
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The Tree Traversal Tool allows you to enter numbers into a sorted binary tree. At any point, you can make a 
preorder, inorder, or postorder traversal of the tree.with the order of traversal displayed in the tool. 









Number = 5 

Enter Input! Clear Treei 
PreOrderl InOrderl PostOrder! 




»»»»«««« 

PreOrder is 7 4 2 5 9 8 12 

»»»»«««« 



Your assignment is to write the procedures Iriit, EnterNumber, and ClearTree in the module 
TreeTraversalProblem.mesa. The comments in this module provide a more complete explanation of what 
you need to do. 

You will also need the following modules: 

TreeTra versa I Defs. mesa 
TreeTraversallmp.mesa 
TreeTra versa I Tool. config 
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Letter Group Solution 

--Letterlmpl .mesa - last edit on: 
— 14-May-86 18:26:05 

DIRECTORY 

Heap USING [Create, Delete], 

LetterDefs USING [CharQ, CharQPtr, PrintResults, QL1st, QListHandle] ; 



Letterlmpl: PROGRAM IMPORTS Heap, LetterDefs EXPORTS LetterDefs = { 
Cleanup: PROC - { 

if qList # nil then DeaiiocateQueues[]; - optional (If you don't do this, then do : 

IF z # NIL THEN { -- qL'lSt<-NIL) 

Heap. Del ete[z]; 
z «- NIL } }; 

CreateHeap: PUBLIC PROC = { 

IF z f NIL THEN Heap. Del ete[z] ; -justincase 

z «■ Heap. Create[ initial : l]; — create a private heap 

'}; 

InitQueues: PROC [howMany: CARDINAL, input: LONG STRING] = { 
InitialSizeOfQs: CARDINAL <- input. length / howMany + 1; 

qList *- z.NEW[LetterDefs .QLlst[ howMany + l]]; - allocate the sequence of pointers 

for i: cardinal IN [0.. howMany +1) do - allocate a queue for each of the pointers 

qL1st[1] «- z.NEwT_LetterDefs .CharQ[In1t1alS1zeOfQs]]; 

qList[i]. length «- 0; - initialize length 

ENDLOOP; 

badCharQ «- howMany ; ~ set badCharQ to be the last sequence 

}; 



DeallocateQueues: PROC = { 

FOR 1: CARDINAL IN [0. .qList. index) DO 

z.FREE[8qList[i]]; 

ENDLOOP; 
z.FREE[8qL1st]; 
qList NIL }; 



- deallocate each of the queues 

- deallocate the sequence of pointers 



ExpandQ: PROC [queue: LONG POINTER TO LetterDefs .CharQPtr] = { 
-allocate new queue 
temp: LetterDefs. CharQPtr ♦- z.NEW[LetterDef s.CharQ[queue.max1ength + 5]]; 
FOR 1: CARDINAL IN [0. .queue, length) DO - copy Sequence 
tenp[1] «- queue[1]; 
ENDLOOP; 

teap . 1 ength ♦■ queue . 1 ength ; — copy remaining fields 

temp. first «- queue. first; 
temp. last queue. last; 

z . FREE[queue] ; - free old sequence 

queuet temp; - adjust the pointers 

}i 
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Where Does Control Go After a SIGNAL is Caught? 



Statement 


Frame and Block Where Control is Resumed After a Catch 


UNWIND raised? 


YES 


NO 


RESUME 


Control is resumed in the frame where the signal was raised, at the point where the signal was raised. 
View this situation as a return from a procedure call. 




X 


CONTINUE 


Control is resumed in the frame (and block) where the signal is caught, not in the frame where the 
signal was raised (if these frames are different). 

Control is given to the statement following the statement to which the catch phrase belongs. 
If Catch phrase is in a(n): 

1 . Argument list: Go to the statement following the call. 

2. BEGIN - END block: Go to the statement following the BEGIN - END block most narrowly 
enclosing the ENABLE clause. 

3. Loop: Go to the "next" iteration if any. 


X 




RETRY 


Control is resumed in the frame (and block) where the signal is caught. 

Control passes to the beginning of the statement to which the catch phrase belongs. 
If Catch phrase is in a(n) : 

1 Arnumpnt li^t* FYPfntP thp rail ariAin 

2. BEGIN - END block: Go to the first statement of the BEGIN - END block most narrowly enclosing 
the ENABLE clause. 

3. Loop: Start the current iteration again from the beginning. 


X 




LOOP 


Control is resumed in the frame (and block) where the signal is caught. 
Control passes to the "next" iteration. 


X 




EXIT 


Control is resumed in the frame (and block) where the signal is caught. 

Control passes to the first statement outside the loop containing the EXIT statement. 


X 




GOTO 


Control is resumed in the frame where the signal is caught. 

Control passes to the EXITS clause of the block containing the catch phrase or to some 
surrounding block of the block containing the catch phrase. 

Note that control need not resume in the block where the signal is caught. 


X 
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Complex Signal Example 

Consider the code below and name the statements that will be executed when the following call is made: 
Procl[0]; 



GOTO punt; 
<statement 1>; 
<statement 2>; 



Sigl: ERROR - CODE; 
Sig2: ERROR - COOE; 
S1g3: SIGNAL ■ CODE; 

Procl: PROCEDURE[x: CARDINAL] 
BEGIN 
ENABLE 
. BEGIN 

S1gl -> 

Sig2 ■> 

UNWIND -> 

END; 
<statement 3>; 
<statement 4>; 
IF TRUE THEN 

BEGIN 

ENABLE 
Sigl a > <statement 5>; 

<statement 6>; 

<statement 7>; 

Proc2£x! 
S1g2, S1g3 »> <statement 8>; 
UNWIND «> <statement 9>]; 

END; 

<statement 10>; 
EXITS 

punt a > <statement 11>; 
END; 



■► Catch Phrase 1 



«► Catch Phrase 2 



■► Catch Phrase 3 



Proc2: PROCEDURE[x: CARDINAL] 



BEGIN 

Proc3[xt 
S1gl -> 
Sig2 -> 
UNWIND -> 

END; 



<statement 12>; 
<statement 13>; 
<statement 14>]; 



^ Catch Phrase 4 



Proc3: PROCEDURE [x: CARDINAL] 
BEGIN 

IF x - 0 THEN 

ERROR S1gl 
ELSE 

ERROR S1g2; 
END; 
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Statements are executed in the following order: 

Statement 3 
Statement 4 
Statement 6 
Statement 7 
Proc2[0] 
Proc3[0] 
Statement 1 2 
Statement 5 
Statement 14 
Statement 9 
GOTO punt; 
Statement 1 1 

Snapshots of the call-stack when it changes state are shown below (CP = Catch Phrase): 



Proc 1 



Proc 1 



Proc 2 



Proc 1 



Proc 2 



Proc 3 



Proc 1 



Proc 2 



Proc 3 



CP4[Sig1! 



Proc 1 



Proc 1 



Proc 2 



Proc 2 



Proc 3 



Proc 3 



CP3[Sig1] 



CP2[Sig1] 



Proc 1 



Proc 1 



Proc 2 



Proc 2 



Proc 3 



CP 4 [Unwind] 



CP 1 [Sig1] 




Proc 1 
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TM 



In this programming assignment, you will write a program that will play the game of Madlibs™. In 
Madlibs™, the user is asked to think of some words at random. Typically he is asked for adjectives, nouns, 
verbs, etc. Once these words are collected, they are placed into an incomplete story that has specific 
destinations for adjectives, nouns, verbs, etc. For instance the incomplete story line might look like this: 

Dear Mom and Dad: 

How are things? My classes aren't hard; they're just a little <adjective>. 
I'm having fun though. My teachers are very <adjective> and they 
all like to <verb>. Last night, my English teacher showed me how to 
<verb>. She also gave me a <noun> and told me to <verb> everyday. 
My girlfriend is fine. Yesterday we went to < place > and < past tense verb >. 
well, I should go. Send < plural noun>. 

love, <name> 

The finished story might read: 

Dear Mom and Dad: 

How are things? My classes aren't hard; they're just a little slimy. 
I'm having fun though. My teachers are very green and they 
all like to roller skate. Last night, my English teacher showed me how to 
climb trees. She also gave me a twig and told me to sleep every day. 
My girlfriend is fine. Yesterday we went to Hoover Tower and sat. 
well, I should go. Send trees. 



In this version of Madlibs™, the incomplete story lines will exist as a local file. Your program will read 
through the story letter by letter and copy most of the file to a temporary file. Whenever a left bracket, < , 
is encountered, the program will read the word between the two brackets, and display the word to the 
tool's message subwindow asking the user to input this type of word. You then think of a word to type 
into the input field and click over the Read Input! command. Your program will then write the string, 
contained in the backing store of the input field, to the temporary file. These steps should be repeated 
until the input file is empty. When the file is empty your program should display the completed story to the 
tool's file subwindow. 

When the tool is run, the user should type in a file name. After a game has started, the tool will query for 
words: 




: Type in a verb 



love, John 



■a 



Filename: Madl.txt 
Play Madlibs! 



Input: ran 
Read Input! 
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Finally, when the end-of-file has been reached and the new file has been created the text is displayed to 
the file subwindow. 



Dear Mom and Dad: 

How are things? My classes are ok; sometimes they're a little slimy. 
I'm having fun though. My teachers are very green and they 
all like to roller skate. Last night, my English teacher showed me how to 
climb trees. She also gave me a twig and told me to sleep every day. 
My girlfriend Is fine. Yesterday we went to Hoover Tower and sat. 
well, I should go. Send trees. 

love, John 



Programming Assignment 

Your assignment is divided into two parts: 

Part 1 : Create a tool with the FormSWlayoutTool that contains 4 tags: 2 strings and 2 commands. Modify 
the generated code so when commands are invoked the tool will call the procedures defined in 
MadlibsDefs.mesa. The generated code should be placed in the file MadlibsControl.mesa. 

Part 2: Modify the file Madlibslmpl.mesa which implements the Play Madlibs! and Read Input! 
commands. (The two procedures that implement those commands, PlayMadlibs and Getlnput, 
should be called from the MadlibsControl module whenever the user clicks on those commands in 
the window.) You will have to implement three procedures in Madlibslmpl according to the 
comments that describe the procedures. Bind the 2 program modules Madlibslmpl and 
MadlibsControl using the configuration file Madlibs.config. There are 3 files with which to test 
your program; Mad1.txt, Mad2.txt, and Mad3.txt. 




Filename: Madl.txt 
Play Madlibs! 



Input: 
Read Input! 
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For the following code fragments, list the order that the 
executed. 

In all code fragments, assume the following declaration: 
Slgl: SIGNAL = CODE; 

1. FOR counter: INTEGER IN [1..2] 00 4. 
BEGIN 
ENABLE 

S1gl >> LOOP; 
<statement 1>; 

IF counter - 1 THEN SIGNAL Sigl; 

<statement 2>; 

END; 
<statement 3>; 
ENDLOOP; 
<statement 4>; 



statements labeled <statement n> will be 



FOR counter: INTEGER IN [1..2] DO 
ENABLE 

Sigl => LOOP; 
<statement 1>; 

IF counter » 1 THEN SIGNAL Sigl; 
<statement 2>; 
<statement 3>; 
ENDLOOP ; 
<statement 4>; 



2. FOR counter: INTEGER IN [1..2] DO 
BEGIN 
ENABLE 

S1gl -> CONTINUE; 
<statement 1>; 

IF counter * 1 THEN SIGNAL Sigl; 

<statement 2>; 

END; 
<statement 3>; 
ENDLOOP; 
<statement 4>; 



FOR counter: INTEGER IN [1..2] DO 
ENABLE 

Sigl -> CONTINUE; 
<statement 1>; 

IF counter * 1 THEN SIGNAL S1gl; 
<statement 2>; 
<statement 3>; 
ENDLOOP; 
<statement 4>; 



3. FOR counter: INTEGER IN [1..2] 
BEGIN 
ENABLE 

Sigl -> EXIT; 
<statement 1>; 
IF counter - 1 THEN SIGNAL 
<statement 2>; 
END; 

<statement 3>; 
ENDLOOP; 
<statement 4>; 



DO 6. 



Sigl; 



Procl: PROCEDURE = 
BEGIN 

SIGNAL Sigl; 
END; 

IF TRUE THEN 
BEGIN 
ENABLE 

Sigl => RESUME; 
<statement 1>; 
Procl[lSigl =»> CONTINUE]; 
<statement 2>; 
Procl; 

<statement 3>; 
END; 
<statement 4>; 



Signal Exercises 



Mesa Language Class - February, 1988 
Day 4- #4 of 9 

7. BEGIN 

ENABLE 

S1gl »> RESUME; 
<statement 1>; 
IF TRUE THEN 

BEGIN 

ENABLE 

Sigl => GOTO TheEnd; 

<statement 2>; 

SIGNAL Sigl; 

<statement 3>; 

EXITS 

TheEnd => <statement 4>; 
END; 
<statement 5>; 
EXITS 

TheEnd a > <statement 6>; 
END; 

8. x: CARDINAL - 0; 

FOR counter: INTEGER IN [1..3] DO 
ENABLE 

Sigl »> RETRY; 
<statement 1>; 
IF counter = 2 THEN 
BEGIN 
ENABLE 
BEGIN 

S1gl 3 > <statement 2>; 
UNWIND => x «- 1; 
END; 
<statement 3>; 
IF x M THEN SIGNAL Sigl; 
<statement 4>; 
END; 
<statement 5>; 
ENDLOOP; 
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Extra Signals Programming Assignment: Blackjack 

In this programming assignment, you will alter a program which has been written to play the game of 
blackjack. The user initially specifies the number of games the program will play with itself. There will only 
be 2 players in the game: the dealer and the player. When the user clicks Start!, the program will play out 
all of the games; both hands will be output to a file sub-window as each card is played. When all of the 
games are finished ,the total number of dollars won will also be output to a file sub-window: 



Start! 



Games- 1 



> Beginning a new game < 

Your card 1s a two of clubs 

My card 1s a jack of spades 

Your card 1s a three of hearts 

My card is a king of hearts 

Your card is a ten of diamonds 
Your card 1s a six of spades 
You hold at 21 

I hold at 20 

You Win. 
You are ahead by 1 dollar(s). 



In this game of blackjack, the player bets 1 dollar on every hand. If he gets blackjack, then he wins 2 dollars. 
Otherwise if the dealer gets blackjack, the player loses. If the game continues, the player receives hits 
according a conservative strategy based on his hand, and the dealer's face card. If he busts, he loses. 
Otherwise, the dealer receives hits until histotaj is a hard 17 or above. If the dealer busts, the player wins 1 
dollar. Finally, if the game has reached this stage, the 2 hands are compared. The players wins 1 dollar if his 
hand is greater; his winnings remain the same if the hands tie; and he loses if the dealer's hand is greater. 
There is no double-down, splitting, or insurance in this version of blackjack. 

When Start! is clicked, the following procedure in the implementation module is called: 



PlayBlackJack: PUBLIC PROCEDURE[output : Window. Handle «• NIL, gamesToBePlayed : CARDINAL 0] = { 
--This procedure will play Blackjack as many times as specified in gamesToBePlayed. After the 
-- games have been played, results are written out to the window handle output. 

playerTotal, dealerTotal: CARDINAL; 

playerHasAce, dealerHasAce: BOOLEAN; 

dealerHole, dealerFace: CardType; 

THROUGH [1. .gamesToBePlayed] DO 
Intlal IzeDeckForNewGame; 
Put .CR[output] ; Put.CR[output]; 

Put.L1ne[output, " >Beg1nn1ng a new game < "L]; 

[pi ayerTotal , deal erTotal , pi ayerHasAce , deal erHasAce , deal erHol e , deal erFace] «- Deal [output] ; 
IF playerHasAce ANO (playerTotal * 11) THEN { 
winnings «- winnings + 2; --Player has Blackjack 

Put.Line[output, " *** You Have A Blackjackl!!! •** H L]; 

LOOP >; 
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IF dealerHasAce AND (dealerTotal = 11) THEN { 
winnings *• winnings - 1; --Dealer has Blackjack 
Put.Line[output, "*** I Have A BlackjacklM! ***"L]; 
LOOP }; 

[playerTotal] «- HitPlayer[output, playerHasAce, playerTotal, dealerFace]; 
IF playerTotal > 21 THEN { 
winnings «- winnings - 1; — Player busted. 

Put.Line[output, " You Busted"!.]; 

LOOP } 
ELSE { 

Put.Text[output, M You hold at "L]; 

Put. LongDecimal [output, playerTotal]; 

Put.CR[output] >; 
dealerTotal «- HitDealer[output, dealerHasAce, dealerTotal]; 
IF dealerTotal > 21 THEN { 

winnings «- winnings + 1; --Dealer busted. 

Put.Text[output, "I Busted"L]; 

LOOP } 
ELSE { 

Put.Text[output, "I hold at "L] ; 
Put. LongDecimal [output, dealerTotal ] ; 
Put.CR[output] }; 
SELECT playerTotal FROM 
< dealerTotal ■> { 

winnings «- winnings - 1; 

Put.Line[output, "I Win H L] }; 
> dealerTotal ■> { 

winnings «- winnings + 1; 

Put.L1ne[output, ■ You W1n"L] }; 

ENDCASE *> Put.Line[output, " We're even. Tie Game."L]; 

ENDLOOP; 
Put.CR[output] ; 

IF winnings < o THEN Put.Text[output, " You are behind by "L] 

ELSE Put.Text[output, " You are ahead by H L]; 

Put. LongDecimal[output, ABS[winn1ngs]]; 
Put.Line[output, H dollar(s) . H L]; 
}; --PlayBlackJack 

The procedures Deal, HitPlayer, and HitDealer all call the following procedure when they need a card: 
NewCard: PROCEDURE RETURNS [card: CardType] = { 

--This procedure returns the next card in the deck. If at any point, the last card 1n the deck is 
-- used, the non-used cards in the deck are shuffled, and play continues where it left off. 

IF freeCard =» 53 THEN [deck, firstCard, freeCard] «- Shuf f led[deck, flrstCard]; 

card <- deck[f reeCard] ; 

freeCard ♦■ freeCard + 1; 

}; --NewCard 

In the procedure NewCard, deck is an array of 52 records with each record representing one card. Dealing 
is accomplished by stepping through the deck one card at a time. At any instance during a game of 
blackjack, firstCard is an index indicating the first card that was dealt for that hand. freeCard is an index 
indicating the top card on the remaining deck, the next card that will be dealt. Thus, when freeCard is 53, 
deck, firstCard, and freeCard are reinitialized by calling the procedure Shuffled which makes sure that the 
cards on the table are not included in the shuffle. To complete this assignment, you don't have to know 
how Shuffled works, just that it does the right thing when passed the right arguments. 
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Currently, if the dealer runs out of cards at any point in the game, the cards currently not in use are 
shuffled, and the game continues where it left off. So if only 1 card remains in the deck, that card will, be 
dealt, the rest of the deck will be shuffled, and the dealing will continue. 

Assignment 

Modify this program (using a signal) so that if the dealer runs out of cards while dealing the initial hand 
(the first 4 cards), that game is started over with a shuffled full deck of 52 cards. If the dealer runs out of 
cards while hitting the player, the unused cards in the deck should be shuffled, and the game continued 
where it Jiad paused (like before). If the dealer runs out of cards while hitting himself, then the dealer loses 
the game and the next game is started with a shuffled full deck of 52 cards. The file that you will 
be altering is Blackjacklmpl.mesa. Other files you will need are BlackjackDefs.mesa, 
BlackjackControl.mesa, and Blackjack.config. Once you have the new version of Blackjacklmpl.mesa, 
answer the following questions: 

1. Briefly describe how the assignment might have been completed without using a signal. 

2. Signals could have been used to indicate DealerBlackjack, DealerBusted,... From an efficiency point 
of view, why isn't this such a great idea? 
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Signal Exercises Solutions 



In all code fragments, assume the following declaration: 

S1gl: SIGNAL = CODE; 



1. FOR counter: INTEGER IN [1..2] DO 
BEGIN 
ENABLE 

Sigl => LOOP; 
<statement 1>; 

IF counter = 1 THEN SIGNAL Sigl; 

<statement 2>; 

END; 
<statement 3>; 
ENDLOOP; 
<statement 4>; 



FOR counter: INTEGER IN [1..2] DO 1 
ENABLE 1 
Sigl => LOOP; 2 
<statement 1>; 3 
IF counter = 1 THEN SIGNAL S1gl; 4 
<statement 2>; 
<statement 3>; 
ENDLOOP; 

<statement 4>; 



2. FOR counter: INTEGER IN [1..2] DO 1 
BEGIN 3 
ENABLE 1 
Sigl => CONTINUE; 2 
<statement 1>; 3 
IF counter = 1 THEN SIGNAL Sigl; 4 
<statement 2>; 
END; 
<statement 3>; 
ENDLOOP; 
<statement 4>; 



FOR counter: INTEGER IN [1..2] DO 1 
ENABLE 1 
Sigl => CONTINUE; 2 
<statement 1>; 3 
IF counter = 1 THEN SIGNAL Sigl; 4 
<statement 2>; 
Xstatement 3>; 
ENDLOOP; 

<statement 4>; 



FOR counter: INTEGER IN [1..2] DO 
BEGIN 
ENABLE 

Sigl => EXIT; 
<statement 1>; 
IF counter = 
<statement 2>; 
END; 

<statement 3>: 
ENDLOOP; 
<statement 4>; 



THEN SIGNAL Sigl; 



6. Procl: PROCEDURE = 
BEGIN 

SIGNAL Sigl; 
END; 

IF TRUE THEN 
BEGIN 
ENABLE 

Sigl => RESUME; 
<statement 1>; 
Procl[!Sigl => CONTINUE]; 
<statement 2>; 
Procl; 

<statement 3>; 
END; 
<statement 4>; 
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7. BEGIN 

ENABLE 

Sigl => RESUME; 
<statement 1>; 
IF TRUE THEN 

BEGIN 

ENABLE 

Sigl => GOTO TheEnd; 

< statement 2>; 

SIGNAL Sigl; 

<statement 3>; 

EXITS 

TheEnd => <statement 4>; 
END; 
<statement 5>; 
EXITS 

TheEnd => <statement 6>; 
END; 

8. x: CARDINAL «- 0; 

FOR counter: INTEGER IN [1..3] DO 
ENABLE 

Sigl => RETRY; 
<statement 1>; 
IF counter = 2 THEN 
BEGIN 
ENABLE 
BEGIN 

Sigl => <statement 2>; 
UNWIND => x <- 1; 
END; 
<statement 3>; 
IF x = 0 THEN SIGNAL Sigl; 
<statement 4>; 
END; 
<statement 5>; 
ENDLOOP; 
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Monitors Programming Assignment: One Lane Bridge 

In this programming assignment, you need to write part of a program that emulates the traffic ofi^a oTie 
lane bridge. As shown in the diagram below, there are two lanes of traffic on each side of a bridge that has 
only one lane. You will write a monitor to handle the traffic on the bridge (and prevent head-orv' 
collisions). Keep in mind that if a car is on the bridge going in some direction (i.e. east), then othef 'cafs 
going in the same direction can follow it. Only the cars going in the opposite direction would have to wait. 




Direction: {east, west} Drive! 

Car Typo: {O&tsuo i$ Jeep, Volkswagen} 

Cars In Motion* 4 

n 




When you select a direction (east or west) and type of car (Datsun Z, Jeep, or Volkswagen) and then invoke 
Drive!, a new car of the chosen type going in the chosen direction will be created, and the variable Cars In 
Motion will be incremented. Cars In Motion cannot be changed from the window - only from within the 
program. When you start a car, it will move toward the bridge, then wait, if necessary, until it can cross the 
bridge, and then continue driving. When it drives past the window, it parks somewhere and Cars In Motion 
will be decremented to reflect that the car is no longer in motion. 

The entire user interface has been written for you. This includes the code to create the window and also 
the code to draw the moving cars. You need to implement the procedure Bridge.Drive,which is called 
when the user invokes Drive!. This procedure is defined in the interface Bridge. mesa. You should 
implement this procedure in BridgeMonitorlmpl. mesa. A template has been provided for you. 

Notice that this module is a MONITOR, but the procedure Drive is not an entry procedure - it is an external 
procedure. But, since this is a MONITOR module, you can put all of your procedures for monitoring the 
bridge in this module, too. 

The interface Bridge.mesa (shown below) contains many declarations that you will need. Each of the items 
in this interface are explained below DO NOT ALTER OR RE-COMPILE THIS INTERFACE . There are many 
modules that are dependent upon the particular version of Bridge.bcd that is on your disk, and you do not 
have the source to recompile those other modules. 
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-Bridge, mesa 

- 16-Jan-86 16:07:48 



DIRECTORY 

Supervisor USING [SubsystemHandle] , 
Window USING [Handle]; 

Bridge: DEFINITIONS = { 

DataHandle: TYPE = LONG POINTER TO Data; 
Data: TYPE - MACHINE DEPENDENT RECORD[ 

msgSW(O): Window. Handle <- NIL, 

formSW(2): Window. Handle <- NIL. 

bridgeSW(4): window. Handle <- nil, -the subwindow where the cars an } displayed 
wh(6): Window. Handle «- NIL, 

direction(8):Directlon «- east, -is mapped to the choice in the foM$W 

car(9): CarType ♦■ DatsunZ, -is mapped to the choice in the forn^i^A/ 

carsinMotion(io): cardinal «- o, —is mapped to the variable in the fbrm$W 

agent( 11) : Supervisor. SubsystemHandlo] ; -IS used to control deactivation of ,t/ie topi 

Direction: type = {east, west}; -Direction and CarType are enumerated 

CarType: type = {DatsunZ, Jeep, Volkswagen}; -types that are used in the datarecord 

BridgeType: TYPE = RECORD[ 

. ; carsOnBri dgje : cardinal f ; o , , -the number of carsgn the bridge .at any time 

direction: Dir.sction v «- east] ^ \ ' . ,„-t/ie cflrect/on o f the cars off ih&btftige;. 

Drive: PROCEDURE[1,nstanqeDataj:, DataHandle];. 

BeglnDriving: PROCEDURE [sw: Window .Handle- ..^ car; CarType, dir: pi recti on ]';'"" 
CrossBridge: PROCEDURE[sw: Window. Handle , car: CarType, dir: Direction]; 
ContlnueDriving: ,PROCEDURE[.sw; Window Handle, , car: CarType, dir: Direction]; 

,..'}... *" ' : •' G ' V 

In your monitor, you should create an instance of tfie record type BridgeType to keep track of the number 
of cars on the bridge at any given time and the direction of those cars. The procedure Drive is the 
procedure that you will implement in BridgeMonitorlmpl.mesa. The three procedures BeginDriving, 
CrossBridge, and ContinueDriying are the procedures that you will call when you want to send a car off in 
a given direction. They have already been implemented for you. These procedures display the moving car 
along the specified part of the road and return control to their caller when they have completed. So, when 
you want to start a car driving in a given direction, a call like Beg i n Dr i vi'ng [data : br i dg e SW, which car, 
which direction] (where which car and which direction have the values of a particular CarType and 
Direction) would do the display part for you. When you know that a. particular C ar is ready to cross the 
bridge, call CrossBridge[...], and when the car has left the bridge', call CohtinueDriving[...]. 
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Here is the template for BridgeMonitorlmpl.mesa: 

-BridgeMonitorlmpl.mesa 
- 16-Jan-86 16:10:52 

DIRECTORY 

Bridge USING [DataHandle], 

Process USING [MsecToTicks, Pause]; 

BridgeMonitorlmpl : MONITOR 
IMPORTS Process 
EXPORTS Bridge = { 

data: Bridge, DataHandle «-,NR; ^ 

Drive: PUBLIC ,P^QCEDURE[ i ns^tanceData :, Bridge .DataHandle] = { 
data «• 1nstfiij$eJ)ata;. ' y ■ 

Process . Pause,tP.^Qtcess .MsecToT1cks[50p j j; 

~ You need to write the rest - 

} ; -Drive 

}■•. 

The parameter instancejpa^. is 9 pointer to a record of type Bridge.Data. data is immediately assigned the 
value of instance Data. Now data wilt always have the' most current data Md you "can access any of the 
fields in data (i.e. data.direction) from anywhere within this module. Process.Pause[...] will suspend the 
process for a specified time, in this case a half second. This puts a little tlrYi^iff between cars io that they 
don't start so close to each other that they appear one on top of another. You need to finish writing this 
procedure and all other 'help*' procedures that you ma/Weed! ! * o; ' J^ ^ jj i > 

Every time that you change J the value of Carsln Motion, you rteed'td red fijplay ifter View value. You can do 
this with a call to FormSW.Displayltem[data.formSW, 3]. The parameters of FormSW.Displayltem are the 
window that the item we. want to redisplay is in (data.formSW) and the number of the item that we want 
to redisplay. Each jtem m the fbrmSW has a 'correspdndint^ it%m n r)u } mbeTpTh , if' ; item '''number^ 
CarslnMotion is 3. ^ '' ^ - - : J : ■ 

There is a maximum number of ,co;exi sting processes allowed; to prevent problems, ydu^fi'difld catch the° 
error Process.TooManyP : rocesse^ l ;.dfs)3)ay a message to the message subwindow; and prevent ^Hy new cars r 
from starting (at least,y ntil £t^r ^&hay$ parkect). For information on how to cltch the error, r£fer to the c 
Pilot Programmer's Ntar)iial^0^-2^^o^^h2-io. 

The configuration modui^ptiet^ has b^en written for you. 

Assignment 

1. Finish the implementation module BridgeMonitorlmpl.mesa. 

2. Verify your implementation by running the tool. 
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Extra Monitors Programming Assignment: 
Dining Philosophers (Hard Version) 

Your assignment is to implement the dining philosophers problem. In this problem, you have 5 
philosophers at a dining table. However, there is only one chopstick between each plate, and a 
philosopher needs 2 chopsticks to eat. At any given time, a philosopher may be thinking, eating, or waiting 
for the philosopher next to him to put down a chopstick so he can use it. 




The tool has an enumerated item to represent each philosopher: 





: □ 




Philosopher!.: {thinking, waiting, eating} 

Ph1losopher2: {thinking, waiting, eating} 

Ph1losopher3: {thinking, waiting, eating} 

Ph1losopher4: {thinking, waiting, eating} 

Ph1losopher5: {thinking, waiting, eating} 
□ 




Philosopher # 1 is eating. 
Philosopher # 2 must wait to eat. 
Philosopher # 1 has finished eating. 
Philosopher # 2 is eating. 



Initially, all philosophers are thinking. The user can tell a philosopher to start eating by changing the value 
of the enumerated from thinking to eating. If the philosopher can eat, then the state will change to 
eating, and appropriate feedback will appear in the file subwindow. If the philosopher must wait to eat, 
then the state will change to waiting, and an appropriate message will appear. 

Thus, in the program, you need to write a procedure that reacts to changes in the state of the enumerated 
"philosophers." When the user asks a philosopher to eat, you should check to see if he can eat (see if his 
chopsticks are available.) If the philosopher can eat, then you need to update data to indicate that his 
chopsticks are in use, and display a message. Otherwise, the process should wait until it can eat. While the 
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process is waiting, the state of the philosopher should be "waiting." Note that your implementation is the/ 
only way to change the state to "waiting"; the user should not be able to explicitly change the state to or 
from waiting. 

If the user changes the state of a philosopher from eating to thinking, then you should change the data so 
that his chopsticks are no longer in use, and inform other philosophers that they might be able to eat. 

You are on your own for this assignment; we do not provide any of the code for you. 



Dining Philosophers (Hard Version) 



